| 1 |
On Sun, Apr 15, 2018 at 7:44 AM, Francisco Blas Izquierdo Riera |
| 2 |
(klondike) <klondike@g.o> wrote: |
| 3 |
> |
| 4 |
> Here are some randomly picked tasks that don't require belonguing to a |
| 5 |
> project: |
| 6 |
> * Keeping the documentation on the wiki up to date and clear. |
| 7 |
|
| 8 |
Wiki project |
| 9 |
|
| 10 |
> * Writting new, relevant documentation. |
| 11 |
|
| 12 |
That seems redundant with the wiki, since that is where we keep our docs. |
| 13 |
|
| 14 |
> * Helping address users concerns over one of our official channels |
| 15 |
|
| 16 |
Comrel project? |
| 17 |
|
| 18 |
> (forums, gentoo-user mailing list, IRC, etc.). |
| 19 |
|
| 20 |
Forums, PR projects. So far we haven't had anybody become a dev |
| 21 |
merely on the basis of hanging out on IRC/gentoo-user that I'm aware |
| 22 |
of, though this certainly seems like it could be a project. |
| 23 |
|
| 24 |
> * Helping users provide relevant information on bug reports. |
| 25 |
|
| 26 |
Bug-wrangler project. |
| 27 |
|
| 28 |
> All those are tasks making a very significant contribution to Gentoo. |
| 29 |
> All of those are tasks that don't require being a member of any project |
| 30 |
> to be performed, just having the relevant experience and skills. |
| 31 |
|
| 32 |
Sure, but so far I don't think anybody has actually become a developer |
| 33 |
NOT being on a project. Also, I suspect that if somebody did want to |
| 34 |
contribute ONLY in one of those areas they'd be a perfect candidate to |
| 35 |
create and lead such a project where one doesn't exist. |
| 36 |
|
| 37 |
> Also why have to be the project leads the one determining the activity |
| 38 |
> non ebuild developers do? After all GLEP39 clearly states too: " Instead |
| 39 |
> the practical responsibility of a lead is "whatever the members |
| 40 |
> require", and if that isn't satisfied, the members can get a new lead |
| 41 |
> (if they can find somebody to take the job!)." |
| 42 |
|
| 43 |
Project leads don't generally dictate what project members work on. |
| 44 |
They might have a coordination or dispute resolution role. |
| 45 |
|
| 46 |
And there is nothing that says a project lead has to be an ebuild developer. |
| 47 |
|
| 48 |
This assumes some kind of adversarial relationship between project |
| 49 |
leads and their members, when in fact as you point out the leads are |
| 50 |
chosen BY the project members. |
| 51 |
|
| 52 |
> |
| 53 |
>> The GLEP *explicitly* defines that there are |
| 54 |
>> both ebuild and non-ebuild contributions, so whatever you're making up, |
| 55 |
>> it's irrelevant to the topic at hand. |
| 56 |
> |
| 57 |
> The GLEP defines different requirements for those two sets of peoples |
| 58 |
> with the second set having harsher constraints (i.e. not having the |
| 59 |
> possibility of having their contributions not being filtered by a third |
| 60 |
> party). This second group happens to be "non-ebuild contributors". |
| 61 |
|
| 62 |
This is reasonable to point out (IMO), though again I think you're |
| 63 |
assuming some kind of hostile intent here where I don't think it is |
| 64 |
warranted. I believe the intent here is to describe the status quo, |
| 65 |
which will of course require some care since the status quo wasn't |
| 66 |
well-defined previously. |
| 67 |
|
| 68 |
Do you have any suggestions for better wording here? Are you |
| 69 |
advocating for requiring all developers to be members or a project, or |
| 70 |
do you have a better way to define the qualifications for developer |
| 71 |
status that does not invoke projects? |
| 72 |
|
| 73 |
-- |
| 74 |
Rich |
Archives