> On Nov 16, 2014, at 23:44, exar...@twistedmatrix.com wrote: > > On 10:04 am, a...@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
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
