Frontend Architecture Working Group/Scope of work
Deliverable: A proposal
[edit]The output of the working group for each exploration is to produce a project proposal. The proposed project should make progress towards the stated goals of the exploration. The proposal does not have to be a FULL SOLUTION for the exploration, but it should be a specific, measurable, achievable, relevant and time bound project that will be a first step for a team to make progress towards the larger goal. The proposal has specific information that must be included. The format of this proposal is at the end of the document.
Context: Product ownership
[edit]For each working group exploration and proposal, the working group must have a product owner. The role of the product owner is to provide scoping which will guide the design of solutions developed within the working group. This can be in the form of requirements, mockups, user stories, features, or any other way to express product needs. This is an important step and component for framing any technology choices as it makes sure that engineering efforts are grounded in real world use cases and make them much more likely to deliver value to our users and communities.
Work: Developing a proposal
[edit]In order to create the proposal, the working group should engage in activities such as discussion, gathering requirements, performing research, speaking with stakeholders, designing architecture, developing mockups, prototyping, or any other activities needed to properly scope the project. During this process the group will be facilitated in order to help them select the best activities in order to accomplish their goal.
Proposal Format
[edit]Each project proposal should be a brief but thorough document that defines the project. The layout and format should be adapted to suit the project, and can include diagrams, tables, schematics, designs, etc…
In addition, every proposal must include the following components:
1. Project deliverable
[edit]What will be produced upon completion of the project. The output of the project must be a demo-able product or prototype with a UI. This ensures that the project has practical application and has demonstrable value which stakeholders, both technical and nontechnical, can see and understand.
2. Product requirements
[edit]A description of the project in terms of features, use cases and/or user stories. This keeps the project focused on delivering something that will solves a real problem that some set of users have and emphasizes knowing why we build something before we get to how.
3. Nonfunctional requirements
[edit]A list of requirements that lay out the constraints of the project. These should include, but are not limited to:
- Scalability: performance, memory, caching, storage, etc…
- Security
- Maintainability
- Database schema changes and migration plan
- API changes and migration plans
- …
4. Resources
[edit]People
[edit]The people required to ship the project. These people must be full time and include all disciplines such as managemproposal should be a brief but thorough document that defines the project. The layout and format should be adapted to suit the project, and can include diagrams, tables, schematicsent, design and product. For engineering, the request should reference any needed skills, but should not request specific people.
Required Hardware
[edit]In addition to people, any required hardware should be listed in order to plan for any needed purchases and requests for our data center.
5. Communication
[edit]Any required communications that need to be made to develop and ship the project. This can include:
- Technical RFCs
- WMF/WMDE staff
- Wikimedia Community
- 3rd Party Community
6. Tradeoffs
[edit]What benefits are gained from doing this project? What burdens do we take on?
7. Risks and contingencies
[edit]A list of potential risks for the project. This should include risks that are both technical and social. In addition, should be a list out contingencies in order to mitigate these risks. How can we fail or backout gracefully?
8. Success and failure
[edit]What does success look like? What about failure? How do we know when we are done, or when we should stop and cut our losses?
9. Questions to be answered
[edit]Unknowns of a project… what questions will we need to answer during the development of the project in order to be successful?
Out of scope
[edit]The working group will not work on these projects themselves. The working group should perform the research and planning in order to develop a good project plan which is represented in the proposal. That proposal will be used to define the work for a separate cross-functional team (though it is possible that some of the working group members may be on that team). The working group can and should make recommendations on the skills of the staff required by the team in order to complete the project, but refrain from specific people requests.
Completion: Presentation to leadership
[edit]After developing the proposal, members of the working group will present the proposal to the Executive Sponsors and Leadership for feedback and sponsorship. Following this process, leadership will form a team and schedule the project for development.