Awjrichards added a comment. @Eloquence yes - caveat though, I just got pulled into this conversation by @Qgil yesterday, so my thoughts are not necessarily well-informed nor well-formed ;)
//Developers→Project management infrastructure and documentation for best practices.// I am a little unclear on what exactly this means - particularly in regards to 'project management infrastructure'. If I'm not mistaken, it could be said that Phabricator provides project management infrastructure out of the box. It would be valuable to have scope of this and the end-state of this goal more clearly articulated. As for the documentation of best practices (which I understand I am on the hook for) my initial reaction is that we're going to need to keep it fairly high level (eg "create a new workboard for every new sprint") since different teams will have different needs for the tool, but I think this will be valuable and I am very happy to help flesh that out :) //Developers→Burndown charts.// Similar to above, what does this mean exactly? //Developers→Eliminate most uses of Trello/Mingle (Fundraising Tech exempt)// I've already heard some feedback about this particular goal, which seems to be making some teams uneasy. Is this intended to be a mandate that every usage of Trello/Mingle is eliminated (with the exception of FR Tech)? Or is this intended to be a goal of the project to convince all the teams to abandon Trello/Mingle and flock to Phabricator? How do non-team-specific based usages of Trello/Mingle fit into this rubric (eg Scrum of Scrums which uses a matrix view to represent work dependencies that can't be recreated in Phabricator)? //Stretch goal: Developers→Basic plan for Phabricator as code review tool// I think this makes sense, though I think it would be valuable to more clearly articulate the goal (eg Basic plan for replacing Gerrit with Phabricator as a code review tool for all WMF-managed code repositories). As an aside, I am not a fan of stretch goals - it's hard for me to grok how they are valuable. I personally would prefer to see this as either a goal, or not a goal, but I understand that some folks do indeed find the 'stretch goal' concept' useful. As a general rule (and this goes for all the projects, really), I think it would be great to have the goals (or 'measures of success') be more specific (in such a way as to clearly define scope) and measurable, and written in such a way that the end state can be generally understood by anyone glancing the list of goals (rather than intrinsically understood by project participants). TASK DETAIL https://phabricator.wikimedia.org/T667 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. To: Awjrichards Cc: wikibugs-l, Eloquence, Qgil, TrevorParscal, bd808, ori, Maryana, Awjrichards _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
