Hi,
On Fri, Jun 28, 2013 at 04:04:04PM -0500, john_terps...@dell.com wrote:
> I would like to initiate a discussion to secure an agreeable process for
> handling of pull-requests for the Crowbar community project. Please respond
> to this email with your suggestions, recommendations, and concerns.
>
> NOTE: The following are designed to initiate discussion - no decision has
> been made - nothing is locked in place by these proposals.
>
> Objectives:
>
> 1. To keep the public code tree in a clean and working condition
>
> 2. To facilitate the flow and processing of pull-requests
>
> 3. To avoid holding up the work of community developers
>
> 4. To encourage greater contribution
>
> 5. To provide a great experience for all code contributors and reviewers
>
> 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
IMO, this should be the prefered method of feedback to pull request. If a pull
request needs more a longer discussion with greater parts of the community
involved discussion can be moved the the IRC channel or the list, as
appropriate.
> 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
Hm, that sounds like is quite a long list of people :). Depending on how you
define the key areas of crowbar code of course.
> a. Responsibilities of the SME
>
> i. Top-level responsibility for code review and merging
>
> ii. Can assign responsibilities to a trusted fall-back person to
> ensure that pull-requests are not blocked when the SME is not available
>
> 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
>
> c. Ensures that at least two (2) votes are received for each pull-request
>
> d. Maintains equitable behavior that does not impede code contribution work
>
> e. Liaises with SMEs within the community so that development work flows
> smoothly
>
> 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
Looking at the above and having the current (pretty small) size of the
community in mind, I think we should make sure to not introduce a too heavy
process. Too much process will a least hurt item 3,4 and 5 of the objectives
listed above :). When the community grows it's still possible to rework the
processes as needed.
What are the problems with the current process we are trying to address? (I am
sure there are quite a few)
> d. Testing and Validation
>
> a. The SME will exercise sound judgment to determine the testing methodology
> that is appropriate to the patches submitted via the pull-request
>
> b. All contributors are expected to suggest/recommend the preferred method
> that is most appropriate to validate their pull-request/patches
>
> c. Code submissions are expected not to break the code
>
> Key Questions:
>
> I. How should community code review discussions be conducted? (Meetings,
> Conference calls, IRC, other)
Comments in the pull request. If that is not enough: mailing list or IRC.
> II. Should the community create its own code releases (independently from
> contributor organizations)?
>
> a. Should this be considered the formal community release?
>
> b. How should community release objectives be set?
>
> III. What criteria shall the community adopt in respect of pre-release code
> freeze, QA, etc.?
>
> a. What does a release cycle consist of?
>
> b. What influences release point goals, objectives, and their
> achievement?
>
> c. What should be the relationship between community releases and
> contributing organization releases?
>
> IV. How should SME appointments be handled?
>
> a. Community vote?
>
> b. Organizational appointment?
>
> c. How are individual contributor efforts protected in this structure?
--
regards,
Ralf
_______________________________________________
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
