[Twisted-Python] Permissions to trigger buildbot tests

[Glyph]

> On Nov 16, 2014, at 23:44, exarkun at twistedmatrix.com wrote:
> 
> On 10:04 am, adi at roiban.ro wrote:
>> Hi,
>> 
>> To help with the review process I would like to ask permissions for
>> triggering buildbot builds.
>> 
>> Is there a wiki page describing what are the steps required for a regular
>> contributor to get permissions to run buildbot tests and get write access
>> to the repo?
> 
> I'll send you the credentials off-list.  FWIW, this is password protected only because spambots found the form and kept triggering garbage builds.
> 
> There's no standard policy or procedure for granting commit access to the repository.  Usually it goes like "someone asks for it, someone gives it to them".
>> 
>> --------
>> 
>> In the same time, maybe we can write a few words about the steps required
>> for a new contributor to become a full reviewer. Ex.
> 
> There is no official process but the frequently discussed unofficialy process is just getting commit access.  The project doesn't distinguish between committers in any way as far as the development workflow is concerned.
> 
> Perhaps it should and we should discuss how it could do this.

I think that we should have an official process; the way we do it is pretty arbitrary.  An official advancement process can be a motivator for contributors, as well as a way to more clearly establish community norms.  (I have a feeling if we did have an official process for getting commit access we would actually have more active committers.)

(This is a good talk on the subject: <http://www.kateheddleston.com/talk/ef464595-b113-4c1b-9c5b-cc1f3681055c <http://www.kateheddleston.com/talk/ef464595-b113-4c1b-9c5b-cc1f3681055c>>)

>> 1. Contribute a few patches (ex 10) and learn the basic review process.
>>  Observe how reviewers respond to your patch.
>> 
>> 2. Start doing review as junior reviewer, without merging. Once you are ok
>> with the patch, invite another core developer to take a final view and
>> merge the patch
>> 
>> 3. Once you have reviewed a few patches without errors (ex 10) you can ask
>> for full review permission or a core developer will let you know that you
>> can merge the patch without asking someone else.
>> 
>> This can be part of the current review process page:
>> https://twistedmatrix.com/trac/wiki/ReviewProcess
>> 
>> What do you think?
> 
> I think this process probably involves little enough learning that it won't make a significant difference to the quality of code reviews done for the project (so it will only add overhead to the process of keeping track of different kinds of reviewers and where in their progression "junior" reviewers are).
> 
> A modification that would help very slightly (but I think still not enough to be worthwhile, particularly since it adds even more overhead) would be to require a correct review covering each of the many relevant areas - for example, howto-style docs, example-style docs, api-style docs, unit test coverage, coding convention compliance (whitespace, variable naming, etc), etc.  After demonstrating competence in all areas the "junior" reviewer could advance to normal review status.

This sounds great. Could you jot it down on a wiki page?

> Unfortunately notice I didn't say anything about the software being built or changed itself.  I don't know of an easy way to test folks for competence at that kind of thing except to see them write a lot of code.

We can easily have a suggested process for this too, if we have to have subjective evaluations, then let's just be explicit that some specific group has to make some specific evaluation...

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20141117/9f03d0e1/attachment-0002.html>