<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 10, 2015 at 12:49 AM, Quim Gil <span dir="ltr"><<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What exactly are you missing? For what is worth, there is</div><div><h1 style="margin:0px;padding:8px 0px;border:0px;font-size:15px;color:rgb(70,76,92);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif">Assign due date to task and have tasks with due dates displayed on a calendar (similar to Trello)</h1></div><div><a href="https://phabricator.wikimedia.org/T76094" target="_blank">https://phabricator.wikimedia.org/T76094</a></div></div></div></div></blockquote><div><br></div><div>The key time-related user stories I can think of are:</div><div>- As a PM or dev, I want to specify a projected due date, release date or release window for a specific task. </div><div>- As a manager or stakeholder (incl. community), I want to see the top-level roadmap, and specific project-level roadmaps.<br></div><div>- As a release manager, I want to see the deployments planned for the next two weeks.</div><div><br></div><div>Right now we're addressing this by:<br></div><div>- managing a top level roadmap as workboards</div><div>- specifying dates/ranges in comments and workboard columns</div><div>- managing the main deployments calendar as a separate wiki page, and additional deployment calendars on additional wiki pages</div><div><br></div><div>This means redundancy: I have to monitor the tasks for updates on ETAs and then reflect those in the roadmap. It's also possible that there are other workboard views that specify dates in column names which are impacted as dates change, but not auto-updated.</div><div><br></div><div>It also means dispersal: For example, I have to know that the Language Engineering team maintains its own deployments calendar and where to find it ( <a href="https://www.mediawiki.org/wiki/Content_translation/Deployment_Plan">https://www.mediawiki.org/wiki/Content_translation/Deployment_Plan</a> ).</div><div><br></div><div>This isn't nearly as bad as the situation we had when we still used 20 different PM tools, but it seems like one of the next big project management challenges to tackle. I'm not suggesting we solve it all in one go. What I'd suggest is:</div><div><br></div><div>- Get the data structure right first. Make sure we have the ability to specify what we want as a property of the task and query it. I can't speak for Greg and whether he's interested in moving off wiki-based deployments pages. For roadmap purposes, though, it's important to be able to specify both a specific date _or_ a range. </div><div><br></div><div>This won't help with the redundancy yet -- though basic queryability would speed things up a bit. I don't buy the argument that the field is clutter in the default view -- I think it will actually push us to think a bit more about when things hit, which is a good thing for everyone.</div><div><br></div><div>- Support upstream in specifying requirements for the calendar views we'd ideally like to see. (I'd be open to sponsoring development and influencing it -- but would advise against full-time WMF staff working on this.)</div><div><br></div><div>I would advise against "dates as projects". There are just too many variants of date expressiveness that we need for this to work (ideally from hour-level precision up to a large date range).</div><div><br></div><div>Erik</div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Erik Möller<br>VP of Product & Strategy, Wikimedia Foundation</div></div>
</div></div>