This is a draft of workflow for starting, operating and delivering on projects within the DataPortability Project framework. A project might be an Action Pack or Choosing a new logo. It could be ANYTHING. The goal is to allow projects to spring up organically while folding projects that stick into the mainline DataPortability Project.
NOTE: Minor modifications (eg. for clarity) should be made here. Discussion of the overall proposal should take place in the originating thread.
Proposed DataPortability Projects workflow:
- Chat/Meetups for real-time collaboration - but NO decisions medium to major decisions should be made here
- Threads opened in an Action group (if the thread would belong to an initiative that does not exist yet) or Project Groups (if the thread directly related to an existing Project)
- The thread should result (on the deadline set by the leader) in new or closed todo items AND/OR wiki tweaks AND/OR a new initiative
- If your project does not update it's task/todo list AND the Timeline - then it will not get into weekly or monthly reports.
Detailed breakdown of the proposed workflow:
Definition: Sync Discussion = Chats and Meet ups
- Sync Discussion should only ever be used to create/discuss/further ideas. They must *always* result in an update or creation of a discussion thread (Async discussion)
- Discussion threads should have a leader(s) - typically the person who came up with the idea or who put their hand up to run with it. These must be clearly identified. If the group has a dispute with the leader or the leader steps away others should step up to fill the spot.
- Discussion threads should have a deadline for decision or violent dissent. Decisions are made by taking into account violent dissent or agreement and rough consensus made before the deadline given by the discussion leader.
- Small-scale/simple decisions can be made on the spot in chat/meetups by the Project Leader(s) (one in each timezone maybe?) but should also be documented on the Discussion threads of that Project
- Discussion threads should end in one or more of the following ways (in the order of most likely)
- Die out with no action
- Suggest that participants in the thread investigate an existing project/initiative either inside or outside DP and report back (i.e. we don't want to re-invent the wheel)
- Update the todo list for the corresponding initiative - this may require we install Jira rather than using the wiki for todo
- If the change is significant enough, update the Time Line.
- Update a wiki page
- Create a wiki page
- Create a proposal for a DP.Project (Projects can either be 'Experimental' (just hacking around) or 'Official' (their deliverables will be official DP deliverables) or 'Incubated' (a project that is simply incubated by DP, it is expected to succeed but the deliverable is not planned as an official DP deliverable). A DP.Project Proposal template is required
- Create a proposal to Graduate a DP.Project from Experiment to Official
- Approach third parties to officially participate in something (by first reading the thread perhaps) (should be run by the chair) (It might be appropriate to have a vote for the Chair some point soon)
- Make an announcement to the community via the official announcement channels (should be run by the chair)
- DP.Projects can be proposed by anyone.
- To propose a Project:
- Start a 'Proposal' Wiki page under the 'Project Proposals'
- Link to the Project Proposal Stub in the DP.Projects google group and ask others to flesh it out.
- Once you are happy with the Project Proposal, submit it to DP.Action.Steering.
- The DP.Action.Steering group has 14 days to achieve rough consensus on the formation of the Project. The Project Leader can suggest a project status (E.g. experimental, incubated, official) but the the Steering group has final say on project status at inception.
- If accepted the Project gets its own sub-space on Confluence, and it's own DP Resources (wiki/mailing list etc)
- Update the time line
- The Project may ONLY submit requests for help/support and announcements of people in the Action Groups (NOT the general list). Requests and other Project info will be posted to the general mailing list in summary by a person responsible for this task (Projects Manager?)
- To graduate a Project from 'Experimental' into official:
- Prepare a "Graduation Proposal' on your Project Wiki
- Discuss the proposal and flesh it out on your own Project mailing list
- Once you are happy with your Project Graduation Proposal, submit it to DP.Action.Steering
- The DP.Action.Steering group has 14 days to achieve rough consensus on the graduation of the Project
- If accepted, the deliverables of the Project become part of the official deliverables/best-practices/recommendations of the DataPortability Project.
- Update the time line
- Graduated Projects may submit requests for help/support and announcements to both Action Groups AND the General List
- In this scenario, Action Groups (besides steering) effectively become a collection of like minded/topic centered individuals from which the Initiatives can draw skills from
- Also in this scenario, the Technical & Policy blueprints become 'DP Initiatives' (that could have easily been incubated using this Project Methodology had it existed at the time - these initiatives - such as Best Practices Documents - would now be converted to 'Official Projects').
- Also in this scenario we need to great task management system (Jira?)
- We should also insist that if an action is not going to be done immediately, it should be added to the todo list as a matter of priority.
Additional evolution of this document is being discussed here: http://wiki.dataportability.org/x/l4Ej