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
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
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
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)
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?
_______________________________________________
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
