Hi John, A few comments:
Le vendredi 28 juin 2013, à 16:04 -0500, [email protected] a écrit : > Proposed Process: > > a. All community participants/members are encouraged to provide patch > (pull-request) feedback > > a. On the mailing list > > b. Over IRC channel #crowbar > > c. Via Github pull-request responses > > b. It is proposed that each participating organization is encourage to > appoint a subject matter expert (SME) for each key area of the crowbar code > base To make this simpler, we can have one or two known contacts at each organization, and they can be pinged to find out who can review a pull request. My rationale for this is that this makes the list of names to maintain much smaller :-) That means some tweaks to the details you've put below, but that could work. > b. Assure that pull-requests are either handled (action is being taken) > within 3 days of the submission > > i. Delegate to others > to handle if the SME is unable to do it > > ii. Notify the Crowbar > mailing list that of significant processing delays > > iii. Provide periodic > feedback to the mailing list if a pull-request is held up It's probably a responsability we should all share: if anyone notices that a pull request is old and still not merged, that person should really just ping on the list. > c. Code Review Cases > > a. Simple patch - action SME will merge the pull-request with minimum > fuss > > i. No voting required > > ii. SME exercises > total discretion > > b. Complex Pull-Request - patches are not potentially controversial > > i. SME seeks/waits > for a minimum of two (2) votes [+1 == OK, 0 == Neutral, -1 == Blocks] > > ii. SME polls > community for feedback is none is received within 48 hours > > iii. SME merges > pull-request if no objections are received, closes pull-request at own > discretion > > c. Potentially Controversial Patches > > i. SME refers the > potential controversy to the community and engages the submitter to defend > the case to merge > > ii. SME referees the > resolution process I'd add a fourth cases: - Patch fixing failure in git: this should be fast-tracked. > Key Questions: > > I. How should community code review discussions be conducted? > (Meetings, Conference calls, IRC, other) In general, this should really be on the pull request. But if there's more to discuss, then IRC or the mailing list is a good first step, imho. > II. Should the community create its own code releases > (independently from contributor organizations)? Ideally, yes :-) It's a matter of resources, though. > III. What criteria shall the community adopt in respect of > pre-release code freeze, QA, etc.? I'd leave this topic up to the people who would lead the community releases. > IV. How should SME appointments be handled? Bootstrap with people who are active, and then make these people delegate the power when there's a new person who'd do a good job. Cheers, Vincent -- Les gens heureux ne sont pas pressés. _______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
