| 1 |
On 15/04/18 17:55, Francisco Blas Izquierdo Riera (klondike) wrote: |
| 2 |
> This is not what I'm saying. In fact current practice is different from |
| 3 |
> what you purvey: |
| 4 |
> * Ebuild developers are usually asked about reassignment: see |
| 5 |
> https://bugs.gentoo.org/show_bug.cgi?id=vapier or |
| 6 |
> https://bugs.gentoo.org/show_bug.cgi?id=hwoarang |
| 7 |
> * If they state they are interested in maintaining the packages they are |
| 8 |
> allowed to do so (I guess unless the council decides to reassign them). |
| 9 |
> |
| 10 |
> Here is a similar approach that would work for both: |
| 11 |
> * Once a developer has been inactive for x time (for example not having |
| 12 |
> voted on two consecutive council electiions), the developer is contacted |
| 13 |
> by undertakers and asked whether he/she/it is still interested in Gentoo |
| 14 |
> and has contributed soomething that went missing in this period. |
| 15 |
> Undertakers also give a deadline for a reply. |
| 16 |
> ** If the answer is afirmative and the developer sends some |
| 17 |
> contributions the undertakers close the issue. |
| 18 |
> ** If the answer is negative but the developer wants to continue |
| 19 |
> contributing, the undertaker can provide advice on how to do so and |
| 20 |
> extend the deadline a bit (after which the developer will be retired and |
| 21 |
> invited to take the tests). |
| 22 |
> ** If the answer is negative and the developer is okay with retiring, |
| 23 |
> retirement is done. |
| 24 |
> ** If no reply is obtained before the deadline, retirement is done. |
| 25 |
> |
| 26 |
> Turns out that this is, in a way, the process documented on the |
| 27 |
> Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertakers |
| 28 |
> |
| 29 |
I have long thought there could be improvements to the Undertakers |
| 30 |
process, and I think developers that have been MIA for some time (for |
| 31 |
whatever circumstances) have some checks made that they are indeed |
| 32 |
up-to-speed with any policy changes that may have happened since their |
| 33 |
last 'active' period. This would be not to penalise them, but ensure |
| 34 |
that the Quality standards that Gentoo holds, are upheld, and devs don't |
| 35 |
get to run riot once their initial 'assessment' and recruitment phases |
| 36 |
are over. It would provide a better 'continual development' track that |
| 37 |
could be expanded into other areas if proven and desirable. |
| 38 |
|
| 39 |
My ideas went so far as: |
| 40 |
-- if Dev does not set Devaway, and/or devaway period is over ~6months |
| 41 |
(say) and activity has fallen to zero .. commit privs get automatically |
| 42 |
revoked (by script, not by human). An automated email is sent out to |
| 43 |
that Dev, encouraging them to contact [insert project here] (eg. |
| 44 |
Council, ComReS, DevRel, etc) if there is good reason for the absence, |
| 45 |
the privs can be reinstated after a petition has been received and reviewed. |
| 46 |
-- A fast-track re-fresher training is provided by Recruiters, which |
| 47 |
brings an existing or elapsed dev back up to current standards. Such |
| 48 |
topics as new EAPIs, QA tracks, and policy updates could be covered in a |
| 49 |
couple of 'sessions' and then commit privs can be reinstated. |
| 50 |
|
| 51 |
I think this would improve the situation where some devs commit in large |
| 52 |
'bursts' in between significant lapses in activity, causing a lot of |
| 53 |
distress to other more regular contributors and disrupting some of the |
| 54 |
more consistent ongoing efforts. |
Archives