| 1 |
On Sat, Sep 19, 2015 at 5:07 PM, Daniel Campbell <zlg@g.o> wrote: |
| 2 |
> +1 in general, but I'm a little pensive about allowing non-devs to |
| 3 |
> become official project members. Becoming a developer can be a |
| 4 |
> grueling process, so I understand that some don't have the time or |
| 5 |
> motivation, and still want to help out. So perhaps we could have |
| 6 |
> contributors who wish to be project members pass our ebuild test, or |
| 7 |
> some other litmus test to prove themselves, like a developer proxying |
| 8 |
> them or something. Non-devs don't have direct push permissions to our |
| 9 |
> main repo, so to my knowledge they'd still have to go through a dev. |
| 10 |
> I'd just like to see some sort of documentation that sets expectations |
| 11 |
> for non-dev project members so that a new contributor understands what |
| 12 |
> would be expected. |
| 13 |
|
| 14 |
I don't think that project member and commit access have to be |
| 15 |
all-or-nothing together. |
| 16 |
|
| 17 |
I'd suggest leaving it up to each team to decide who is allowed to be |
| 18 |
a member if they're a non-dev, and the rest are just contributor. The |
| 19 |
team can use whatever rules seems best. |
| 20 |
|
| 21 |
Project members don't necessarily have formal powers, though typically |
| 22 |
they participate in elections for the lead. |
| 23 |
|
| 24 |
As always, if there is trouble there is always comrel or council. I |
| 25 |
think most teams should be able to figure out who should and shouldn't |
| 26 |
be acknowledged as a member. |
| 27 |
|
| 28 |
But, there is still the GLEP 39 issue. I'd suggest the "contributor" |
| 29 |
label for things like alias members until that is sorted out. There |
| 30 |
isn't really much distinction in reality. |
| 31 |
|
| 32 |
-- |
| 33 |
Rich |
Archives