Talk:Technical Collaboration Guidance/Prioritization list

The basics for this reference list were created by the Community Liaisons at an off-site in Mexico City, 2015.

This is not an exhaustive list of things one can ask before releasing a product, but it's a good umbrella.

Community Tech prioritizes work based on the following questions:

• Support
  • How high a score did get in the surveys?
  • Are there discussions showing consensus for the request?
  • If the task involves working on an existing codebase, are the current maintainers open to us modifying or forking their code?
• Feasibility
  • How much work is involved?
  • Are there any blockers?
  • Does our team have the necessary knowledge to accomplish the task in a timely manner?
• Impact
  • How many wiki projects will this benefit?
  • How many editors will this benefit?
  • How much will this improve the efficiency and happiness of the communities?
  • Is there existing software that can cover this need? (or software that is already being developed)
• Risk
  • Are there any potential cons?
  • Does it negatively affect any group of editors?
  • Is the task well defined with a clear scope? (i.e. does it have defined acceptance criteria)

Some of this is covered in the current document, but some aspects are not, such as risk and feasibility. It might be good to incorporate some of those questions into this document.

Risk and feasibility, good points. Thank you.

Think it would be worth unpacking the notion of "prioritization" a bit in the intro paragraph to the page, and perhaps further disambiguating the types or stages of prioritization being addressed. As it stands, this reads to me as some combination of a checklist of things to consider in the course of the product or project development life cycle AND a prioritization rubric AND a feasibility assessment. As such, it is unclear to me what "priority" really means here: in what context are we prioritizing (against other projects, against other resourcing requests, community needs, ...?), and for whom? What I would expect to see from something called a "prioritization list" in a Technical Collaboration Guideline would be something that answers the question: "Should this work be a priority right now?". Within the page as it currently stands, I think there are other considerations: CAN we do this work right now (eg with the resources and knowledge that we have)? How will we CONTINUE to understand the impact of this work? Perhaps this is actually closer to a product development checklist that supports good technical collaboration, with "prioritization" as a subset activity of that list?

Also, nice job, and thanks for all your work on this :-) Happy to answer any questions and expand these thoughts further.

Several people have mentioning the lack of clarity that the page title gives to the purpose of the content, so it is good to have it documented again. You're right, the title is throwing off the purpose of the document. It's much more about feasibility and acceptance rather than prioritization. I'll look into changing it to something more appropriately descriptive.

Let's not forget the sequence of steps that brought us here:

1. We wanted recommendations about prioritization involving communities.
2. We decided to recycle some recommendations written in another context.

If the content doesn't fit the idea of prioritization, then we can find a new title for the page... but then we will still miss recommendations for prioritization.

Good point. Okay, I'll think on it.