Jump to: navigation, search

Difference between revisions of "Taskflow/CoreTeam"

(Blanked the page)
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
= What and How =
The taskflow-core team is responsible for reviewing all changes proposed to the following repositories:
<code>stackforge/taskflow</code><ref name="test">[https://github.com/stackforge/taskflow taskflow]</ref>
Note that everyone is encouraged to help review changes, even if you are not a member of this team.  All reviews are very useful and are taken into account by the core team members.  Participating in the review process is most critical task on the road to joining the team.
= Adding or Removing Members =
A new member may be proposed on the openstack-dev list at any time.  A proposal can come from anyone, but typically comes from the project's PTL or an existing member of the core team.  Once a proposal has been made, 2 (or more) existing members of the core team must respond with a +1.  If any existing member of the team objects, they may respond to the proposal with a -1 to veto the nomination.
A member of the team may be removed at any time by the PTL.  This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership.
= Membership Expectations =
Membership in the taskflow-core team is a significant commitment and should not be taken lightly.  Maintaining membership on this team takes a lot of time.  Further, it is important that the time invested is ''consistent''.  It is harmful to the team and the project overall for the core team members' participation to be inconsistent.
Team members are expected to participate in code reviews on a regular basis. Members are also expected to stay on top of discussions happening within the project, primarily on the openstack-dev mailing list.  Note that IRC is also used quite heavily, so members should be in <tt>#openstack-state-management</tt> as much as they can.  These activities are critical to be able to provide high quality reviews based on the current state of the project. This is done by regularly providing high quality constructive criticism.  Your well thought out recommendations for changes are what build credibility for your +1 of a patch.
= Review Prioritization =
Not all reviews are created equal.  Team members should take care in prioritizing where they invest their review time.  In general, priority should be based on the priority of the bug or blueprint the patch is associated with.  Beyond that, older reviews should get priority.  Take a look at the [[ReviewWorkflowTips]] page for tips on how to work prioritization into your workflow.
= Resources =
* [[ReviewChecklist|Criteria To Use When Doing Code Reviews]]
* [[ReviewWorkflowTips|Tips on Review Workflow]]
<references />

Latest revision as of 07:24, 6 September 2013