Page MenuHomePhabricator

Recommendation for projects requesting prioritization or resources
Closed, ResolvedPublic

Description

This is an action related to the discussion Between "Concept" and "Plan" - Prioritize?

The WMF product development process defines a Concept stage and a Plan stage. Between these stages there is a prioritization process that we are trying to define and document.

The first step for a concept is to enter the prioritization process. We need some quality requirements in place, in order to assure that a concept can be evaluated properly. Flooding the prioritization process with raw ideas drafted in a whim without any structure is probably a bad idea. For example, Individual Engagement Grants and Possible-Tech-Projects define some requirements for project candidates before they even get a chance to be accepted.

Can we establish a standard checklist for concepts aiming to enter a prioritization process? I guess some items in the checklist would be required to all concepts, some would be applicable only to some based on certain conditions, and some would be entirely optional.

Related Objects

StatusAssignedTask
Duplicate Qgil
Resolved Qgil
Resolved Qgil
DuplicateNone
DuplicateNone
Duplicate Qgil
ResolvedElitre
ResolvedElitre
DeclinedNone
OpenNone
OpenNone
InvalidKeegan
DeclinedKeegan
DeclinedNone
ResolvedQuiddity
ResolvedKeegan
Resolved Qgil
ResolvedKeegan
ResolvedKeegan
OpenNone
ResolvedMoushira

Event Timeline

Qgil created this task.Dec 2 2015, 9:11 AM
Qgil raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil added subscribers: Quiddity, Qgil, StudiesWorld and 6 others.
Keegan set Security to None.
Keegan added a subscriber: Keegan.

Tentatively looking at working on this next month (March)

Keegan claimed this task.Feb 8 2016, 8:49 PM
Keegan triaged this task as Normal priority.Feb 9 2016, 12:33 AM
Keegan removed Keegan as the assignee of this task.Mar 7 2016, 7:51 PM
Keegan removed a project: Liaisons-March-2016.

Unclaiming for now, other things to work on first to facilitate this task.

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

Keegan renamed this task from Checklist for project concepts to be considered for prioritization to Recommendation for projects requesting prioritization or resources.Jun 13 2016, 9:54 PM

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.

This comment was removed by Keegan.
Keegan renamed this task from Recommendation for projects requesting prioritization or resources to Q1FY16/17: Recommendation for projects requesting prioritization or resources.Jun 14 2016, 5:05 PM
Keegan claimed this task.
Keegan renamed this task from Q1FY16/17: Recommendation for projects requesting prioritization or resources to Recommendation for projects requesting prioritization or resources.Jun 14 2016, 9:33 PM

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

Keegan added a subscriber: Risker.Sep 8 2016, 6:40 PM

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.

Elitre added a subscriber: Elitre.Sep 13 2016, 3:59 PM

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?

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").

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.

Keegan closed this task as Resolved.Sep 21 2016, 6:30 PM