poke poke :) @Qgil can you help set this up

Icon: Umbrella
Colour: Checkered

Icon will be "Sprint", as per guidelines.

poke poke :) @Qgil can you help set this up

As long as discussion is ongoing on teampractices@ I don't see a need to rush.

Creating a tag specific for tasks that fit in a roadmap sounds like a good idea. However, I would be more precise defining this or these roadmap tag(s), otherwise we will end up with another vague definition like Epic added to a bunch of tasks that are not really within the scope that motivated this proposal.

What roadmap are we talking about? Is @Eloquence talking about a #WMF-Product-Roadmap, a #WMF-Technical-Roadmap (or #WMF-Engineering-and-Product-Roadmap), a #WMF-Roadmap including non-tech teams?

Here are the initial criteria I would use:

1. The task describes either a significant new piece of user-facing functionality (Features workboard) or the launch of a new API or service (Platform workboard). Bug fixes, minor modifications of existing APIs and small UI tweaks are excluded. There is a judgment call involved here, but essentially -- if the change is of broad interest to our users or developers, it will land in either column.
2. There is an initial ETA for this task that is agreed upon by the responsible project lead as appropriate. It is understood that time estimates further out have lower confidence. For this reason, the roadmap workboard only has month-level resolution for the current quarter.
3. If the confidence for the ETA is low, this should be indicated in the task. When an ETA is revised, a brief update is added to the task providing an explanation.
4. The short task description is clear and understandable without being a member of the team. Good example: "Enable (Bla) extension on English Wikipedia". Bad example: "Story #843 enable on enwiki"
5. The task either is connected to the team's real workflows (i.e. it has other relevant tasks hanging off as dependencies), or links into another PM tool like Trello where absolutely necessary.

To begin with, I would reach out to a couple of PMs for projects that I know we have in the pipeline to get them on the correct place in the workboard, pick the right task, etc. If we find this is working, we'd formalize it further. If there are issues with this approach, we may decide to delete the project. Let's evaluate by early April at the latest. Sound good?

Pinging @gpaumier , @greg and @Awjrichards in case they want to weigh in before we pull the trigger on this.

Sounds good to me.

#WMF-Technical-Roadmap ?

Why not just Roadmap ? Certainly I would avoid constraining it to WMF.

In T90360#1074136, @Eloquence wrote:

Certainly I would avoid constraining it to WMF.

Ah, ok, this wasn't clear (to me at least) from the discussion, since https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals is indeed limited to WMF projects. I prefer to invite others to this process, so yes, even better.

We can start with Roadmap and wait if we have a problem of non-technical projects landing in that workboard and becoming a problem. Nothing to worry in the short term, most probably.

Discussed with the PM team, let's move forward with this.

Roadmap

I'm not very convinced about the umbrella + checkered, but this is a minor detail that we can still discuss if needed (@Aklapper, your call).

I am happy to defer to ECT on icon choice & colors. Will start poking at the workboard setup today. I tried using Epic -- too much cruft, too little definition.