Description: Tracking Wikimedia-wide epic projects and when we expect they will arrive.
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:
- 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.
- 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.
- 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.
- 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"
- 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?
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.
- I'd prefer to use Deadline+Green like for Sprints, because there is a time commitment and I'd like to clearly express that, otherwise we would have just created another abstraction layer for Epic. I admit I'm still sceptical here and would love to be proven wrong.
- Someone please set up the workboard columns as wanted (please also document their intended use in the project description).
General comments like for every newly created project:
- Everybody please encourage interested people to visit the project and to join the project as members, and to subscribe themselves to the project in order to receive updates.
- Recommended practices for project and workboard management in Phabricator are available.
@Qgil: Thank you. This was also on my list for tonight.