Tentatively looking at working on this next month (March)

Community participation in prioritization should be part of the Technical-Collaboration-Guidance, even if we are not going to work immediately on it.

Re-titled, tentatively going to rescope this task with @Qgil to be a set of recommendations on prioritizing work based on community needs, beyond the narrow scope of Community Tech.

Removing Team Practices Group for now. Suggest you consider using a template along the lines of the example requests here:

https://www.mediawiki.org/wiki/Team_Practices_Group/How_To_Engage_With_TPG

@JAufrecht is still subscribed here.

If you need or would like something specific from the TPG in regards to this ticket, please be in touch following:
https://www.mediawiki.org/wiki/Team_Practices_Group/How_To_Engage_With_TPG

Can we establish a standard checklist for concepts aiming to enter a prioritization process?

After discussions with our different in-house product stakeholders, I really don't think at this time we're likely to come up with anything "standard" to be agreeable - product teams simply don't want to give up some of the flexibility they have in organizing feature development in order to satisfy a checklist. In other words, the thinking seems to be that committing to a standard checklist for such a diverse array of products means that the product may suffer in order to satisfy a checklist, and teams would rather have a good product than a filled checklist.

Now, this doesn't mean that @Risker 's checklist (T126952) should be discarded. That particular checklist should be canon for releasing products that editors directly interact with. I'm not sure the feasibility of mandating it, though. Ideally we'd take the principles of doing no harm to heart and this shouldn't have to be forced, teams should desire to follow it.

product teams simply don't want to give up some of the flexibility they have in organizing feature development in order to satisfy a checklist.

I'm a little tired from recent travel, so I apologize if this comes across as a bit gruff.

This is terrible. The work of any developer is not meant to be bent to align to some ill-fitting checklist. The intent is that the checklist provides a little guidance for a developer wanting to know what to do next. Instead of having the uncomfortable (and often unproductive) feeling of "Ok, now what!?" the checklist would provide a "Ok, so now that is done, here's what I need to consider next.".

While I agree that prioritization is subjective - Two product managers in the same department might prioritize the same tasks differently - a simple 'best practices' on how they each prioritize work would be helpful. Maybe not 'standard' as in Everyone Does This All The Time, but as in, everyone should consider this checklist when prioritizing resources.

Instead of bailing on this because it's too amorphous/hard, I suggest we reconsider figuring out what good advice we can share with this step.

How much work should go into this "figuring out what good advice we can share", considering that the main audience (Product) is basically telling us they wouldn't read/use it anyway?

In T120070#2633321, @CKoerner_WMF wrote:

product teams simply don't want to give up some of the flexibility they have in organizing feature development in order to satisfy a checklist.

I'm a little tired from recent travel, so I apologize if this comes across as a bit gruff.

This is terrible. The work of any developer is not meant to be bent to align to some ill-fitting checklist. The intent is that the checklist provides a little guidance for a developer wanting to know what to do next. Instead of having the uncomfortable (and often unproductive) feeling of "Ok, now what!?" the checklist would provide a "Ok, so now that is done, here's what I need to consider next.".

The context is the key to make it more understandable and not so terrible.

The number/types/scope of products worked on within the WMF are the blocker here, not the people. To create an adequate checklist, it would actually look a lot more like an algorithm or flow chart - much more work in sorting if/then, either/or decision making rather than simply "do this" checklist marks. The inconsistency is too...inconsistent.

It's not that there's an unwillingness, it's much more of an unable to.

The other "checklist of things to consider" that we had brainstormed in mid-2015 is at https://www.mediawiki.org/wiki/User:Keegan_(WMF)/PDP/CL_MX_notes
I do believe that thinking of these as "things to consider" rather than "every item must be implemented" is what everyone wants.
If we had to get strict/formal about it, then every item could be tagged as either "required", "recommended", "if necessary", or "optional" (or something like that). Similar to TemplateData!

I am re-reading the description and I still think it makes sense to have a recommendation for projects requesting prioritization or resources. Even if I used the term "checklist" in that description, the aim was and is really having gone through a list of things to consider, and document your stake in each of them (i.e. "non applicable").

In T120070#2638659, @Qgil wrote:

I am re-reading the description and I still think it makes sense to have a recommendation for projects requesting prioritization or resources. Even if I used the term "checklist" in that description, the aim was and is really having gone through a list of things to consider, and document your stake in each of them (i.e. "non applicable").

Is the brainstorm checklist that @Quiddity linked to the kind of content you had in mind? Do you think that would be useful to repurpose and rewrite?

The scope of this task is the concept / planning phase, when prioritization happens. Therefore, the section https://www.mediawiki.org/wiki/User:Keegan_(WMF)/PDP/CL_MX_notes#Understand.2FConcept.2FPlan looks like a good starting point.

Excellent. @Quiddity we'll work on this together, then, with the content from the link provided as a the base.

Draft is live: https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Prioritization_list