Frontend Architecture Working Group/Process

An Agile Process
While this document represents a working guide based on the information we currently have, the best plans are those that adapt to new information and changing situations. Throughout the process, the individuals involved are encouraged to review the process, propose changes, and implement them in concert with the relevant stakeholders.

Explorations and rotations
There are five explorations in total for which the working group will develop a proposal. Generating a proposal is limited two calendar months. Members must be present for the entire two months to participate in an exploration, and be available for follow up such as retrospectives after the exploration. When complete, members can rotate out and new ones can rotate in.

Working group composition
The working group will have 6-8 individuals for each exploration (excluding facilitation and architecture support), selected by Product and Technology Leadership and WMDE. The size will be capped in order to maintain productivity and ease of communication and scheduling.

At this size it is not possible for the WG to have experts in every domain. Although not all disciplines can be in the working group, working group members can and should ask other staff and community members for information and opinions when developing a proposal, as long as it does not interfere with their regular work.

Time commitments
Working group participation is 8 hours per week (can be more, time allowing).

This time will be allocated between a combination of discussion time and async work, with at least 1 in-person meeting per week. The facilitator will determine this based on the group, problem, and other logistical concerns.

In order to participate in the working group, members must be able to commit to the 8 hours per week for the entire length of the exploration (maximum 2 months). For 1 month after the exploration, there will also be follow up, retrospectives and other debriefs that working group members should also make themselves available for.

Product owner
In addition to the regular working group members, the working group will have at least 1 product owner (as mentioned above), who is generally expected to be a product manager at the WMF or WMDE. The scope of the work that a PM is expected to do for the working group is the same type of work they generally do when developing any product plan. While product owners are not required to engage in all working group activities, they do need to commit to relaying product requirements, provide feedback to solutions and help guide the working group towards a project proposal that the product manager endorses. It is likely, but not required, that the sponsoring PM will be the PM for the project that is being developed.

Process
For each cycle the following process is repeated:


 * 1) Exploration selection (Leadership with Sponsors)
 * 2) Exploration definition and scoping (Mentrix and selected staff)
 * 3) Member selection (Leadership with Sponsors)
 * 4) Exploration kickoff (Entire working group)
 * 5) Solution development (Entire working group)
 * 6) The group works on 1 exploration at a time
 * 7) 1 month check in
 * 8) Solution proposal (Selected members of the working group)
 * 9) The output of the group is a proposal, ideally only one but can present multiple options with a preferred option
 * 10) In addition to the written proposal, the members of the working group should be prepared to present the proposal in a meeting

Proposal Format
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
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
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
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

People
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
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
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
What benefits are gained from doing this project? What burdens do we take on?

7. Risks and contingencies
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
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
Unknowns of a project… what questions will we need to answer during the development of the project in order to be successful?

Project constraints and notes
Proposed projects must be complete able within 3 months. If a project is too big, the working group is encouraged to find ways to cut scope to deliver the minimum viable product and allowing the product owner to plan and schedule the next iterations to realize the full vision.

Projects will be planned and executed on a 2 week sprint schedule.

Project selection will be driven by the Product Leaders with consultation from PMs and engineering leadership.