More clearly communicate our product priorities

Background

In the shift from the OS-specific versions of GitHub Desktop and developing a clearer roadmap, we labeled more than 100 issues with future-proposal, but with a small team and constraints around time and resources, we haven’t been able to adequately revisit those or assess relative priorities around those issues compared to open issues and compared to one another. We think we can be more productive and foster a more honest and open relationship with our community if we start to organize those issues alongside the open ones and frame them as problems that we can more effectively prioritize.

It’s as important for us to communicate what we don’t intend to work on (or accept pull requests for) as what we do. We know we’re not going to execute this perfectly, as it’s a famously hard problem in open source, but we want to try to iterate from where we are today.

Our goal with this effort is to:

1. Stop using the future-proposal label. If something is worth doing or requires further exploration, we’ll reopen it or create a new issue (referencing the old one(s)) that frames the problem that should be solved.
2. Communicate clearly about what things we would like to have in the product, what things require clarification, research, or design, and what things we just don’t think should be done. We can be clearer about this latter part. We don’t want to offend anyone but we do want people to understand what’s realistic and what’s not.
3. Allow for us to develop a holistic prioritization, such that our team knows what we’ll be working on next and what value we want to deliver to our users (i.e., how are we measuring success?), and what high value things members of our community can work on.

Steps

• Read through all issues with future-proposal label and make recommendations to the team on which ones are in one of three buckets:

1. Not happening
2. Needs clarification / user research / design
3. We’re thumbs up on it happening (agnostic on whether we’ll do it or not)

• Get consensus from team and carry out plan to either reopen or remove the future-proposal label from all those issues, and communicate updates on each of the issues (likely referencing this one for context)

• Put our philosophy about how we think about building products down on paper (or, in this case, in our documentation) so when we say “no” to something, there’s a clear and thoughtful reason to create as much objectivity as possible in our decision-making.

• Delineate at least three top problem areas that we want to prioritize to effectively communicate which things we intend to explore in the next few months.

• Cross-reference the issues that are in bucket 3 (thumbs up on it happening) in Step 1 above with the things we plan to explore in the next few months to determine a group of things we can reasonably add help-wanted and potentially good-first-issue to because we think they should be done but we don’t have the bandwidth to do them. Thanks @say25 for the inspiration here.

• Update the Roadmap to more accurately reflect our priorities and what we intend to do as a team. h/t @say25 again.

[say25]

As an non-core contributor, there are some future proposals I think are really cool/interesting but I’m personally afraid to implement them as I’m not sure how the @desktop/core team would feel about them. I also think the desktop team could be better at using the help-wanted label.

Maybe we add the help-wanted label to some of the future-proposal tickets that are in bucket 3?

For the bigger/things can we add a Future Releases section in the Roadmap.

[ampinsk]

Quick thought: I would love if we could have external folks contribute design. We’d probably need to think more about that, but in terms of process, I think we can leverage both the needs-design-input and ready-to-go labels to signal what stage a proposal/contribution is in.