| 1 |
On Fri, Jun 12, 2020 at 10:33 AM Alexis Ballier <aballier@g.o> wrote: |
| 2 |
> |
| 3 |
> What about /j #gentoo-media, discuss, join the current projects, get a |
| 4 |
> few things done (there is a lot of choice there ;) ), maybe orphan |
| 5 |
> unmaintained players/viewers, or check if they are maintained and hand |
| 6 |
> them to a specific maintainer, and then see about merging or splitting |
| 7 |
> all those projects *after* gaining experience and knowledge about the |
| 8 |
> peculiarities of some of those packages ? |
| 9 |
> |
| 10 |
|
| 11 |
Probably best to leave the details up to those doing the work, but I |
| 12 |
would suggest this as a guideline: |
| 13 |
|
| 14 |
Keep the scope reasonable. If you expand the scope to a point where |
| 15 |
90% of the project members don't care about 50% of the project scope, |
| 16 |
then you're setting yourself up for a repeat of the past. You want |
| 17 |
80% of the project members to be interested in 80% of the packages |
| 18 |
being maintained ideally. Sure, there will be little niches that a |
| 19 |
subset are more interested in, but you want to keep it focused around |
| 20 |
a core where coordination makes sense. You can have different roles |
| 21 |
in the project but it should still be one project. |
| 22 |
|
| 23 |
If most of the project members aren't talking to each other about most |
| 24 |
of the things they're doing in the project, then it isn't really a |
| 25 |
project - it is just a category tag. The point of a project is to |
| 26 |
coordinate things that actually NEED to be coordinated or at least |
| 27 |
benefit from it in some way. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives