Proposal: How to structure the project's roadmaps and their upkeep

[loganlee]

/kind doc

Background

This issue outlines ideas / suggestions on how to structure work related to the Elafros’ goals / roadmap.

It is important to point out that Pivotal thinks in terms of the following concepts:

Outcome - A user-centered outcome that one or more of the project's personas desire to achieve. Examples:

• Application/Function Developers can reliably update their running Application/Function’s configuration and/or version of its code.
• Application/Function Developers can roll back their running Application/Function to a previously deployed configuration and/or version of its code.
• Cluster Operators can assure themselves that every deployed Application/Function’s logs in /var/log/[some specific directories] is forwarded over [some desired protocol / format specifics].
• Project Contributors can deploy Elafros and complete a sample’s instructions within 20 minutes using their Laptop with 16GB of memory in order to learn about the project's functionality, architecture or code.

Roadmap - The list of outcomes each Elafros Working Group desires / expects to complete in a given time period.

Although we don’t all share this same vocabulary, we have observed examples of all of these concepts. Here are a few examples:

• Project's deliverables document captures some desired outcomes and outcomes are sometimes described in a corresponding Github Issue
• A Github issue that frames a solution to a given desired outcome

We have experienced that it is often hard to focus on outcomes rather than solutions or architecture. It is natural to jump right to designing and building something and use the language of solutions. However, this tends to lead to a lack of shared understanding of why the work is happening and for what purpose, which is key to Working Groups reaching consensus on Roadmaps. Focusing on outcomes has a powerful effect on both contributors and consumers.

Suggested actions to take:

1. Establish Github organization project board for the Working Group you’d like to trial this approach with under the Elafros organization to serve as the Working Group’s roadmap and enable read access / write access for appropriate users.

2. Add a new Roadmap document to the community section and document that roadmaps:

   • Exist for each Working Group and are divided based on the problem area the Working Group is responsible for.
   • Consist of user-centered outcomes (as opposed to solutions, features, bugs or chores).
   • Reflect the outcomes the Working Group has agreed would be valuable additions to the project and that the Working Group intends to deliver on but does not represent a commitment by any specific Project Contributor to advance.
   • Are intended to educate Project Contributors so that if they value those outcomes, they can contribute to accelerating their solution.
   • Are intended to educate Project Consumers so that they understand what outcomes they should expect users can achieve in the future.
   • Divided into Current Month, Next Month, Future, and Under Consideration sections.
     • Current Month roadmap items represent the outcomes the Working Group has decided to solve for and expect to complete within the current month. This should represent a high percentage of the Working Group’s active focus.
     • Next Month roadmap items represent the outcomes the Working Group believes can likely be completed in the next month.
     • Future roadmap items represent the outcomes the Working Group has decided to solve for but are too far out to know when they will complete.
     • Under Consideration roadmap items are proposed outcomes the Working Group is in the process of determining whether to accept or not.
   • Should not be confused with the backlog of issues the Working Group has generated while working to deliver solutions to roadmap items.

3. Revise existing CONTRIBUTING documentation to summarize the way in which someone proposes a new desired outcome be added to the roadmap.

   • Create an issue that represents the potential roadmap item and summarizes the proposed user-centered outcome.
     • Tag as such and with the appropriate working group
   • Discuss with the Working Group via mailing list, Slack and/or Working Group Meetings.
   • Explain that when a proposal is made, the outcome might be:
     • Rejected due to conflict with the vision for the project.
     • Pending additional understanding of the outcome and/or its usefulness by the Working Group.
     • Accepted, indicating the Working Group has sanctioned this outcome for inclusion in the project.
   • Explain that once a proposal is accepted, that signals that work can begin to solve for this outcome and that the Working Group will attempt to track and expose progress via its inclusion in the Roadmap.

4. Revise existing CONTRIBUTING documentation to expand on the “How to Submit a Feature” section in order to connect features to the roadmap outcomes they advance.

   • Explain that ideally your features should be framed in terms of how it advances a user-centered outcome that is on the roadmap.
   • Suggest that contributors submit a “Solution Proposal” that documents what the user will do and experience in order to achieve the desired outcome along with the user-centered features required for that to happen.
   • Clarify that Contributors are welcome to just submit a simple feature even if it doesn’t tie explicitly to a pre-existing roadmap item.
     • The existing explanation already in the document of how that will be handled still applies.

5. Create and label new GitHub issues or label existing GitHub issues that represent existing desired user-facing outcomes and add to the Roadmap project boards.

   • Re-word as needed to make the outcome the focal point (as opposed to solutions, features or architecture).

6. Revise the descriptions of each Working Group in the list of Working Groups to describe the problem domains and personas the Working Group focuses on (preserve the existing description of the functional components they work on and re-word if needed) so that it is clearer what type of outcomes each Working Group considers for its Roadmap.

7. Revise the existing Working Group meetings with a standing agenda to review and if possible, decide on proposed additions to the roadmap so that there is a forum to push proposals to an accept / reject state.

8. Revise the existing Working Group meetings with a standing agenda to review the state of existing roadmap items in order to identify which items should move. The following patterns are likely:

   • An item has made enough progress and the Working Group now believes it can be completed Next Month. This can happen at any time.
   • An item has made enough progress and the Working Group now believes it can be completed this Month. This will typically be evaluated just before a new Month starts.
   • An item has not made enough progress and the Working Group now believes it will not complete this Month. This will typically be evaluated just before a new Month starts.

9. Create A GitHub Project Board that records “Done” Roadmap Items by the month they were completed. This will serve the need of those who want to know what outcomes are already possible.

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[knative-housekeeping-robot]

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

[knative-prow-robot]

@knative-housekeeping-robot: Closing this issue.

In response to this:

Rotten issues close after 30 days of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.