[17:01:24] Hi everybody! [17:01:30] * greg-g waves [17:01:33] Still waiting one more minute as people are joining [17:01:34] huhu [17:01:34] Hey! [17:01:37] Hi andre__ ! .P [17:01:55] * bd808 lurks [17:01:57] !meetbot help [17:02:24] o/ [17:02:40] mutante: https://wiki.debian.org/MeetBot [17:02:53] o/ (hi prtksxna !) [17:03:04] Olo qgil \o/ [17:03:20] Hiiiii [17:04:00] bd808: :) thx [17:04:08] #startmeeting [17:04:08] So, we've decided to move to GitHub. Thank you for coming and goodbye! [17:04:08] mutante: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [17:04:15] I tried bugzilla and phabricator on my phone today! [17:04:16] #startmeeting office hour [17:04:16] Meeting started Fri Mar 28 17:04:16 2014 UTC and is due to finish in 60 minutes. The chair is mutante. Information about MeetBot at http://wiki.debian.org/MeetBot. [17:04:17] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [17:04:17] The meeting name has been set to 'office_hour' [17:04:30] #topic Office Hour on Project management tools [17:04:38] So..... [17:04:40] #agreed [17:04:45] Welcome everybody to the Office Hour on Project management tools! [17:04:55] guillom and andre__ are your hosts [17:05:24] We are here to give a quick introduction of the work that was done so far. Then we will be happy to answer your questions. [17:05:36] Who else is here who hasn't said hello yet? [17:05:47] o/ [17:05:48] Hello :-) [17:05:49] Hello! [17:05:51] Me.. Hello :D [17:05:59] And thanks to epriestley for agreeing to be around to help answer our questions about Phabricator :) [17:06:01] (I'm here too.) [17:06:05] mutante: You should `#chair andre__ guillom` [17:06:09] hah. Thanks everybody for coming :) [17:06:15] #chair guillom andre__ [17:06:24] #chair andre__ gulliom [17:06:24] Warning: Nick not in channel: gulliom [17:06:24] Current chairs: andre__ gulliom mutante [17:06:34] hello [17:06:40] Latest news: An early draft of the RFC is now available at https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review [17:06:49] mutante, typo: Should be guillom [17:07:16] I'm not sure if I should post the "Problem" section from https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review again here, but I guess I should: [17:07:25] The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. [17:07:36] The multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening [17:07:54] They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome both for current and prospective contributors [17:08:00] Members of the development and user communities have expressed frustration due to the current state and wish to consolidate the development toolchain. [17:08:25] Now a quick summary what has been done so far: [17:08:28] #chair andre__ guillom [17:08:28] Current chairs: andre__ guillom gulliom mutante [17:08:37] #unchair gulliom [17:08:37] * Guillaume and Andre asked people on the teampractices mailinglist to share their needs and workflows on https://www.mediawiki.org/wiki/Project_management_tools/Review [17:08:47] * Guillaume and Andre then summarized all of that into consolidated requirements: https://www.mediawiki.org/wiki/Project_management_tools/Review/Requirements [17:08:57] * Andre and Guillaume set up a list of options to solve our problem, based on what was mentioned during preliminary discussions: https://www.mediawiki.org/wiki/Project_management_tools/Review/Requirements [17:09:14] * People discussed the options and eliminated some of them in preparation for the RfC: https://www.mediawiki.org/wiki/Talk:Project_management_tools/Review/Options [17:09:27] That second-to-last link should be https://www.mediawiki.org/wiki/Talk:Project_management_tools/Review/Options [17:09:27] * Besides the wiki, communication has happened mainly on the teampractices mailing list ( http://lists.wikimedia.org/pipermail/teampractices/ ), with updates also sent to wikitech-l ( http://lists.wikimedia.org/pipermail/wikitech-l/ ) so people are aware of it. [17:09:33] guillom, oops. thanks. [17:09:38] err, https://www.mediawiki.org/wiki/Project_management_tools/Review/Options [17:09:52] (Too many links! They're on the RFC page.) [17:10:01] * And we are now drafting the RfC at https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review and welcome edits on both form and content [17:10:10] #link https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review [17:10:24] Any questions so far? Anybody who would like to know more details? [17:10:50] The RFC is a very early draft, so please edit boldly and/or tell us if you see something fundamentally wrong [17:11:14] I was kind of hesitant to jump in because I didn't know how/where to make this argument [17:11:17] #info RFC draft at https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review [17:11:20] well, tbh(the links are making this quite hardto follow) [17:11:36] I basically want to make a point about how well our tools work together, but I'll defer until we get there I guess [17:12:01] milimetric: I'd love to see that citation. :) [17:12:07] ebernhardson: I think the summary that andre pasted is the only required reading [17:12:18] milimetric: Do you think that they do? Could you elaborate a bit which of the tools you've interacted with? [17:12:44] milimetric: doh, i wasn't clear. I mean trying to read this room when every other line is a url breaks my reading. its hard to follow [17:12:54] We're also looking for guidance on how to proceed now; should we discuss further on the RFC's talk page? Set up a poll on the RFC's page? etc. [17:13:13] ebernhardson: The RFC page is cleaner and has the same info with the links :) [17:13:13] right, ok, well, maybe my confusion about where to jump in will help guide us in the right direction [17:13:33] so currently, we tried to use Mingle and decided it was a failed experiment [17:13:51] "we" being Analytics? [17:13:51] basically the overhead of keeping it up to date and the clunkiness of the UI were very bad matches for our team [17:13:53] I think that Phabricator has some nice tools for designers to share, iterate and get feedback on their designs. This would be a big step in getting the design process alongside all other processes, we would be able to refer to designs in Pholio instead of Mediawiki pages while talking about a design change in a commit. [17:13:56] we being Analytics [17:14:26] yeah, so I was getting to the same kind of point [17:14:26] GitLab seems pretty far out of scope, given that the idea was to solve the project management tool issue. is there anyone advocating for it? [17:14:27] milimetric: Not all of Analytics at least... :-) [17:14:32] guillom: I think a poll is the wrong way to go. Setting up a structure that gives people the impression that this is a straight vote will cause problems later. [17:14:49] milimetric, what else have you tried? Did you use Version One at some point in Analytics? [17:14:51] marktraceur, agreed. [17:14:54] well, sorry, I'm the scrum master of the Analytics team [17:14:58] robla: only Waldir so far that I'm aware of [17:14:59] to add to Dan's point -- for analytics, the project management is the pain point [17:15:01] robla: I think I was the one who put it up, but I'm a Phabricator convert now. I'd support going with GitLab, but it would need other things on top. [17:15:03] OK, so let's talk about Analytics' experience, then gitlab, then how to move forward [17:15:12] ok [17:15:20] from my point of view as scrum master [17:15:30] we've used spreadsheets, asana, bugzilla [17:15:31] mingle [17:15:33] to amplify prtksxna's point: Getting the Design team on the same tooling as engineering would, imo, be great for cross team awareness and productivity. [17:15:40] and gerrit is a given [17:15:45] ++greg-g [17:15:52] not for analytics [17:15:54] (gerrit isn't a given, fwiw) [17:16:02] we don't have much design dependencies [17:16:18] given in that we used it, robla, past tense [17:16:21] tnegrin: No, but there have been snafus with design not being on Gerrit, Mingle, Bugzilla, etc. [17:16:31] i agree [17:16:33] (sorry that sounded randomly snarky) [17:16:50] i am now here - sorry was in another meeting [17:16:51] ok, so my point was going to be that I think if we move to Phabricator [17:16:57] I would add my vote [17:16:59] marktraceur: it's not a pain point for us right now -- totally legit if it is for other teams [17:17:02] No prob awjr; thanks for being here :) [17:17:24] if we move to it completely [17:17:47] as in, if we need to integrate bugzilla -> phabricator or gerrit -> phabricator, I think our pain points would not be addressed by the move [17:17:52] Phabricator also "looks" more friendly to new comers and this might be very good bait for the design team. [17:18:09] prtksxna: :) [17:18:19] I agree with mark, its annoying when some team says we dont use bugzilla but some obscure black hole for reporting bugs (i havent seen that happen in a very long time though) [17:18:26] milimetric: if we go with phab, it'd (probably) be whole-hog [17:18:31] i'm in the same boat as milimetric, i could be interested if its afull conversion. but piecewise with still having 3+ tools, kinda meh [17:18:33] ok, good greg-g [17:18:35] milimetric: you're saying that moving to a piecemeal Phabricator isn't a great idea, correct? [17:18:41] yes guillom [17:18:42] also phabricator is more friendly to handling general non-code tasks than bugzilla. at the moment I see people submit suggestions and stuff like that to bugzilla and it really doesn't fit with what the tool does, the ticket status, etc. [17:18:56] I think moving piecemeal may be a practical necessity [17:19:03] since the point of this exercise was to come to a single tool on PM, I think that's what would happen :) [17:19:06] robla what do you think that would look like? [17:19:17] robla: as long as the end goal is whole-hog and the timeline is not in years but months, I'm ok with that [17:19:18] greg-g, if we go whole-hog (which generally seems useful), we may want to exclude the wiki. [17:19:20] at first, yes. as long as the plan is a full conversion (and not an eventual like sul) [17:19:26] superm401: touche ;) [17:19:30] milimetric: yes, likely [17:19:32] ++ to months not years. [17:19:37] awjr: phabricator could replace bugzilla, then mingle/trello, then gerrit [17:19:37] superm401: not replacing mediawiki with phab :) [17:19:48] :) agreed on the wiki [17:19:52] my hog is moderate and sane [17:19:58] (no offense epriestley :P ) [17:20:03] gi11es: yeah i know but i was curious what the migration procedure may look like - although maybe no one knows yet ;) [17:20:04] bugzilla replacement seems like the hardest part [17:20:08] :P [17:20:13] #info there seems to be agreement that moving to Phabricator should be for All The Tools, although we may need to do it piece by piece [17:20:16] the ordering would need scoping and planning by the engineers involved...I wouldn't want to tie their hands [17:20:17] There is no other option but Phab, right? Looking at the RFC page, nothing else satisfied all parameters. [17:20:35] prtksxna: Well, there is the status quo [17:20:43] I also wouldn't want to block the production deployment of Phabricator if there's a team that wanted to start immediately using it for project management [17:20:45] Plus/Minus a project management tool [17:20:47] ok, and I wanted to make a slightly finer point and then I shut up: we do tasking together as a team, and it would be amazing if we could build a real-time collaborative way to do add tasks to phabricator [17:20:49] guillom: hrm, right [17:20:55] i concur that i'm not really interested in being pushed to using a tool unless it is something that would unify all of our work streams [17:21:16] milimetric: could you explain that a bit more? I don't understand it [17:21:18] right now we task things out in etherpad and have to move back and forth to our planning / tracking tools [17:21:23] ah [17:21:28] i know the mobile web team would *love* that. this was partly the motivation for creating bingle/bugello (to minimize needing to constantly try to keep multiple tools in sync) [17:21:32] milimetric, so kind of an AJAXy UI? [17:21:34] so if we had a task-editing tool ala Asana [17:21:41] think ajax + socket.io [17:21:43] As an "enterprise refugee", coming into an environment with multiple places for tracking epics, stories, tasks, and bugs with different rules for each team is very disorienting. Getting everyone in the same silo would be a huge win in my opinion. [17:22:02] milimetric, yeah I guess socket-ioy would be better: https://secure.phabricator.com/project/board/773/ might be able to do that eventually. [17:22:04] Cramped, but a huge win. ?1 [17:22:05] +1 [17:22:11] the main technical difficulty I see with the bugzilla -> phabricator migration would be matching people's identities before and after [17:22:27] gi11es, why? All Bugzilla has email. [17:22:30] gi11es: many, many issues with bz->phabricator [17:22:36] Alright, so let's talk a bit about migration [17:22:37] Create everyone with the same email, and force a password reset. [17:22:37] * qgil (will be sad if epriestley leaves the room without sharing his wisdom ref migrating 1000s of Bugzilla reports to Phabricator) [17:22:39] milimetric: Surely you mean peerDataConnection over WebRTC :P [17:22:44] i haven't yet had the chance to play around with phabricator - is it flexible enough to allow differnt teams to define their own workflows and ways of organizing sprints/tasks/stories/etc? [17:23:01] :) prtksxna, sure, whatever the cool kids are doing today [17:23:02] qgil: I didn't know he did! [17:23:15] milimetric: Or failing to… ;) [17:23:18] greg-g, I didn't say he did [17:23:19] I'd be happy to whip up a prototype in meteor.js [17:23:23] or knockout + socket.io [17:23:24] qgil, +1. Yield to epriestley. [17:23:50] superm401: good point, that's if we want to have people register phabricator accounts. phabricator can hook to auth systems, which means that we could do without people having to register an email/password for it [17:24:07] So we have thousands of users, thousands of tickets in Bugzilla, and the consensus seems to be that we should move them to Phabricator. That's going to be a pain point. [17:24:14] but the benefit of the migration probably outweighs the fact that people could do without phabricator-specific registration [17:24:25] guillom, not totally sure we have to. Is this insane: [17:24:27] epriestley: (I know you were multitasking): context is: migration from BZ, suggestions? experience from other migrations? [17:24:37] Block new Bugzilla tickets but keep it open? [17:24:48] All new ones go to Phabricator. Just throwing it out there to think about. [17:24:50] does phabricator allow us to move the security related bugs as well with reduced permissions [17:25:07] superm401: that's one proposal (block new creation of tickets in BZ) [17:25:07] superm401: I think we'll eventually want to have all our tickets in one place, even if only for the archives [17:25:20] +1 to mutante's question / concern [17:25:22] I agree [17:25:26] guillom: agree [17:25:31] guillom: andre__ could you start an FAQ thingy for things like "security tickets? [17:25:32] superm401: hmm, if its closed i would rather see a redirect, but not completely insane for a short migration period [17:25:33] I don't have much specific wisdom. Broadly, an approach I favor considering is not doing bulk migration and just providing a human-guided one-at-a-time import tool for pulling data in with oversight. In the past, most of the data I've seen come across in massive data dumps was basically dead and never got touched again. [17:25:34] Otherwise, some other projects (like Blender) have done similar migrations in the past. There's no specific support in the upstream, but you can see https://secure.phabricator.com/T3179 for some discussion [17:25:49] mutante: I think yes; haven't tested but Phab has a permissions system [17:26:01] superm401: when we migrated from trac to phabricator at deviantart we did that. but we had probably an order of magnitude less tickets + 99% of open stuff was less than a year old [17:26:43] We even migrated to bugzilla from a different tracker in the past, but we had a lot less bugs then [17:26:44] is setting up generic redirect rules from bugzilla to phabricator feasible? [17:26:49] greg-g, I might just add "Security tickets" as a todo to "Functionality regressions" section on the RFC [17:26:56] andre__: agreed [17:27:10] #action guillom / andre__ to set up an FAQ with things like restrictions for security tickets [17:27:25] #action Guillaume to ask Blender folks about the migration [17:27:27] milimetric, should be if both Phabricator and Bugzilla are temporarily closed except for the script. [17:27:31] They both use numeric bug IDs. [17:27:43] milimetric: probably. we'd need to reserve T-1 though T99999 for BZ [17:27:44] maybe it's worth generating stats about bugzilla to see how likely we really are to address old bugs that nobody's looking at? basically how often does a bug untouched for 2+ years gets picked up and fixed [17:27:47] guillom, I think Security is fine: See https://secure.phabricator.com/T3820 [17:28:05] superm401: Yeah, but we need that in an FAQ nonetheless :) [17:28:12] robla: Well, or close new filings in BZ and reserve the last bug filed and no further [17:28:15] it's been asked a few times :) [17:28:15] Because it's actually frequntly asked [17:28:17] bugzilla has > 10 years of history, phab is pretty new, there are less tools, like for cleaning up & mass-editing tasks and less options to customize skin. we should test if if scales well with a couple thousand tickets [17:28:42] There's some race condition-ing going on there, I guess. [17:28:53] gi11es: that'll be harder to query. It does happen from time to time but that's only anecdotal wisdom [17:29:15] gi11es: not sure how often, but it happens [17:29:23] i hope it's smarter about handling edit conflicts [17:29:24] mutante, Phabricator itself has at least a few thousand. [17:29:34] we closed a 4 digit bug number a month or so after I started last year [17:29:55] greg-g, and https://bugzilla.wikimedia.org/show_bug.cgi?id=189 was nice. :) [17:30:02] gi11es: you've used Phab and you've been with us long enough to see how we do things. Are you seeing major pain points or workflows that won't work any more if we move? [17:30:10] greg-g: in a post-bugzilla migration world, where bugzilla would be read-only, do you think the ball would have been dropped on that one? [17:30:27] robla: we could theoretically also block T-1 to T-80000 for BZ and T-80001 to T-89999 for RT or whatever. Just saying. (/me quoting Guillaume) [17:30:40] bug 189 is cool:) [17:31:09] gi11es: the 189, no (score extension) [17:31:14] it would have been re-brought up [17:31:15] guillom: I'm not sure for the bug wranglers, I can't remember who wrote an email from that perspective but I can't certain they won't have a hard time [17:31:29] guillom: that being said, I think phabricator allows different workflows that might be more efficient [17:31:35] Got it [17:31:45] but from the general description, it does seem like we might have to build tools for those guys using the phab APIs [17:32:02] question, does phabricator provide stats and metrics ( i think of the Bugzilla cron jobs and scripts we have for that) [17:32:03] the workflow tools (workboards) in phabricator do not seem very mature to me [17:32:09] is there any way to quantify the amount of work we'd need to move to phab v. the status quo? [17:32:16] awjr, it's in progress. [17:32:21] mutante: there are some graphs by default yes, burnup charts, etc. [17:32:23] awjr: the Trello-like thing? It's brand new :) [17:32:25] Can I stop and note that the only person from design that I've seen speak up is prtksxna ? Do we have any indication from other designers that they'll join the Phabricatolution? [17:32:54] superm401: guillom where can i see more details about where it's headed? there are aspects to these kinds of features in mingle that are far superior for our purposes [17:32:55] marktraceur: Jared discussed it yesterday as part of the ECT quarterly review [17:33:05] marktraceur: I dont think anyone else is here yet :( But I could post on the list and ask… [17:33:18] so anecdotally I set up a repository in phabricator, a task wall and some tasks. I found it pretty hard to navigate between those three things and confusing that there were no direct links between, for example, the project and its repository on every page the project was mentioned [17:33:20] prtksxna, sure, or summon people on IRC. [17:33:21] I mean, kaity is, but I'm not sure how much she has to say on the matter [17:33:23] prtksxna, getting more feedback involved is always welcome. [17:33:28] And...jorm? [17:33:33] awjr: there's a ticket in Phabricator's own bug tracker, I4ll find it later for you [17:33:41] thanks guillom :) [17:33:45] in light of my above point, do we think we'll be actively patching upstream? [17:34:02] Is there any benefits to phab for the bug usecasr, or is this purely to put planning stuff in one tool [17:34:06] milimetric, I we do work with the Gerrit upstream, despite a totally different stak. [17:34:14] I think we'll do it a more since it's PHP. [17:34:14] yeah, i know [17:34:28] bawolff: One of the super important things to address is the fragmentation across multiple tools for very similar purposes [17:34:35] but the supergods who work with Gerrit upstream may (probably?) don't want to do so with phabricator [17:34:37] e.g. Feature planning vs. bug planning [17:34:39] awjr: https://secure.phabricator.com/T1344 is the ticket. I think it's been closed because the basic functionality is there, but there were talks about improving the UI iirc [17:34:39] awjr, probably https://secure.phabricator.com/T2575 ? [17:34:40] qchris ^ ;) [17:34:44] ah [17:35:10] This has most of the outstanding tasks for boards: https://secure.phabricator.com/project/board/773/ [17:35:12] awjr: The phabricator workboard for the workboards project is a good place to start looking -- https://secure.phabricator.com/project/board/773/ [17:35:14] milimetric: actually, chad is the one working with Gerrit upstream iirc, and he's pretty excited about Phabricator [17:35:31] thanks guillom andre__ bd808 [17:35:32] There are probably some other ones tagged "Projects" but not "Workboards", if you want to ping me in #phabricator I'd be happy to walk you through things later. [17:35:35] * prtksxna quickly drafts an email for the design team [17:35:37] milimetric, maybe, but I think more people can step up for phabricator. We've shown the ability to contribute to new upstreams, like hhvm. [17:35:38] guillom: christian is definitely actively involved in Gerrit upstream as well, more so than chad now, but yea [17:35:43] Marktraceur: yes, but im just curious if there is any benefits for my usecase as someone who doesnt overly care about scum planning [17:35:51] Heh [17:35:52] point taken superm401, I agree that PHP makes it interesting to work with [17:36:01] bawolff: one big benefit i see of a combined environment is that currently gerrit/bugzilla/trello (for my team) is almost always out of sync [17:36:10] bawolff: It's not just a matter of scrum planning, it will help volunteers know what features are planned and unclaimed too [17:36:12] does anyone know Evan Priestley in person? (main author of phab, lives in S.F.) [17:36:22] mutante: that would be epriestley :) [17:36:32] well played [17:36:34] milimetric: I guess there will be more people contributing to phabricator upstream than to gerrit upstream. Just because of the used language. [17:36:41] Whereas now they need to go to Mingle/Trello/Wiki pages/Etherpads/etc. and that can be hard [17:36:54] qchris: +1 [17:36:54] so another question re: gerrit - phabricator is not at all opinionated about how to structure one's history. Gerrit forces us to rebase and very cleanly package these neat little changes together. Has this been considered? [17:36:59] guillom: aah:) very nice [17:37:01] marktraceur, for what I know Jared (head of WMF Design team) is following the discussion in general. In general they are happy about any improvement over "Bugzilla attachments "upload in MediaWiki etc. They have Trello-like expectations, but would be maybe flexible... [17:37:04] (I think I've met a few people in this channel, but don't think I'm bffs with anyone here.) [17:37:22] Yeah, Trello and Bugzilla fragmentation on my team bothers me, and I think of the other Growth members. [17:37:36] superm401: ^^ quadruple that frustration in analytics :) [17:37:54] qgil_: I bet they have Trello-like expectations. If there are design differences or differences in workflow, are they going to Pull A Designer and not use the tool? [17:38:07] superm401: agreed [17:38:09] So, maybe now would be a good time to start discussing how to move forward with the RFC [17:38:20] epriestley: hi! so Phacility is a company to support Phabricator? [17:38:47] marktraceur, don't take my words literally, I was just trying to translate where think they are standing. It is all flexible, and they are quite open for changing the current situation. [17:38:53] mutante: yeah [17:38:53] Righto [17:39:06] milimetric: do you have a ticket in trello to start syncing bugzilla and trello? ;) [17:39:10] got it, thanks [17:39:15] it's been in the growth backlog for a while now [17:39:45] qgil_: My dire warning here is that we don't want them to say "Oh, sure, changing would be cool" when they mean "It would be best if everyone moved to Trello because otherwise they'll be out of touch with us" [17:39:46] phuedx: oh god... [17:39:50] Or similar [17:39:57] but there is bugello [17:40:04] A clear indication of the team's intent would be good [17:40:07] the problem is, any kind of synchronization tool requires maintenance [17:40:13] milimetric, by "syncing", we mean importing it with Bugello (which I don't think syncs comments going forward, but might do status changes). [17:40:14] (but it sounds like prtksxna is on it.) [17:40:21] and that's ok on slow days but awful on days you're just trying to get shit done [17:40:32] as things are right now with the phabricator workboards, i would not support using phabricator as a replacement for mingle. i am no mingle fanboy, but the workflow controls, infinite views we can achieve, and how we can use it for both short and long-term planning are far superior to what i am seeing in phabricator. the workboards backlog in phabricator doesn't give me confidence that the tool will be drastically improving [17:41:03] awjr: but mingle requires excessive administration [17:41:05] that's true, awjr uses mingle the right way (tm) and that needs to be considered here [17:41:24] we could use it the right way too :-) [17:41:28] guillom, do you want to talk a little on the IRC process? [17:41:29] marktraceur, even if some designers and product managers really seem to love Trello, I also think the same people would move to Phabricator if the rest of pieces are in place and a % of their requirements is in place. [17:41:41] awjr: I assume that for specific needs about workboards, the Phabricator folks would appreciate creating tickets in Maniphest [17:41:42] i agree tnegrin but i'd rather have excessive administration and the feature set that we need rather than minimal administration and very limited featureset [17:41:43] superm401: you mean RFC? [17:41:49] guillom, yes. [17:41:53] awjr: Have you filed bugs about the things missing? [17:41:54] i mean mingle kicked my ass and james forester's ass, and many other asses. But awjr kicks its ass on a regular basis and Mingle's kind of an amazing tool when handled properly [17:42:05] If not, can we talk about what you need and I can help? [17:42:07] marktraceur, I'm a lot more concerned about the migration than about current happy Trello users, tbh [17:42:08] andre__: marktraceur not yet, this is the first time i've played with the tool ;) [17:42:13] marktraceur: it'd be a lot of bugs :) [17:42:15] superm401: I'm letting awjr discuss a bit and then yes :) [17:42:15] marktraceur: absolutely [17:42:18] I'm cool with that [17:42:39] awjr: I'll play with it too, and have a bug-filing spree [17:42:49] qchris: if we had a dedicated scrum master, I agree we could use it the right way [17:42:50] i will marktraceur, although it may need to wait til after next week [17:43:02] marktraceur: shall we set aside some time to go over this stuff together? [17:43:03] milimetric: :-) [17:43:13] qgil_: Even though everything is currently being managed on Trello I think the tighter integration that Phab will offer would be killer for the design tem [17:43:22] so all it takes is for tnegrin to tell me I suck at coding and I need to put on my scrum master hat full time [17:43:30] hehe [17:43:32] marktraceur: I have sent out an email to everyone to join this conversation. I'll follow it up with the meeting minutes [17:43:33] awjr: Honestly if you find time to play with it and make a list of stuff that you wish were different, I can file the bugs asynchronously [17:43:34] milimetric: nooooo [17:43:43] prtksxna: I guess that's why violetto is in now :) [17:43:48] thanks, marktraceur and awjr! [17:43:49] cool marktraceur, then i will schedule time for myself, otherwise other things will get in the way ;) [17:43:56] Yuuup :) [17:43:58] Alright :) [17:43:59] So, we have a draft RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review ; We're going to need to decide how to move forward with this discussion [17:44:03] awjr, thanks in advance! [17:44:10] :D [17:44:26] #topic RFC draft: How to continue [17:44:30] This is a bit of an unusual RFC because it's not about software architecture [17:44:58] prtksxna, in broad terms, I think that the day our current Bugzilla + Gerrit live inside Phabricator, that critical mass will create a force of gravity that will pull teams easily [17:45:00] So, basically, should we just polish up the draft a bit and invite Everyone(TM) to comment? [17:45:03] looks like some sort of decision/consolidation would be highly helpful [17:45:17] NativeForeigner: How so? [17:45:18] guillom: I think we should simplify a bit. I'm not a fan of spelling out B0 and B1 as separate options. Let's decide on a long term strategy first, and then decide how we're going to get there. [17:45:32] NativeForeigner: Is this what you meant as well? [17:45:41] yes [17:45:46] I mean, it sounds like everyone sees Phabricator as the way forward but we're still sort of working out how to take the first step? [17:45:47] qgil_: That sounds almost evil. Come to the dark side… [17:45:48] ok. Thanks! That's helpful [17:45:59] qgil_: But yes, I agree [17:46:08] I don't feel like we've addressed switching costs with phab [17:46:44] tnegrin: that's true - we don't really know yet how complicated it'll be [17:46:47] guillom, even if we have many theoretical scenarios, in practice I believe we have only two: keeping the status quo or moving the full house to Phabricator. Since the first option doesn't require planning or dicussion, I will focus the RfC on the second scenario and all the details, questions, trade-offs it entails. [17:46:49] tnegrin: That'll probably be a lengthy discussion in the RFC [17:46:57] cool [17:47:03] I will, I mean I WOULD [17:47:24] agree with qgil_ [17:47:28] guillom: I'd like to see that balanced against extended current tools [17:47:48] qgil_: Fair enough. So Andre and I will start a discussion about focusing the RFC on Phabricator vs. status quo [17:47:53] phab sounds great but these migrations are heinous [17:48:06] qgil_: Actually I'd like to see a discussion that also encompassed the amount of work we do maintaining Bugzilla/Mingle migration tools, and synchronizing those two things [17:48:12] As well as Gerrit/Bugzilla linkers [17:48:22] tnegrin: the status quo is a contender as serious as phabricator in this discussion. [17:48:25] And Mingle/Gerrit/Bugzilla bots for IRC, email [17:48:31] tnegrin, true, but it's an investment. I think it will probably be a win going forward when you consider the fragmentation in the status quo. [17:48:54] marktraceur: I am currently no longer investing time in the Gerrit/Bugzilla linker. [17:48:57] superm401: I agree but let's at least try to quanitfy [17:48:59] is Scrumbugz or Fulcrum serious at this point? [17:49:04] Plus some issues with the status quo (e.g. three emails for every successful merge). [17:49:10] (i'm guessing not, but just checking) [17:49:12] qchris: good to know [17:49:14] robla, I think scrumbugz is if we go status quo. [17:49:20] Since it's a light addition to the Bugzilla status quo. [17:49:20] Scrumbugz to me is superior to the status quo [17:49:31] right +1 superm401 [17:49:33] #action guillom and andre__ to consolidate options (merge B0 & B1 for example), simplify the status quo, and make the RFC about Phabricator compared to the status quo, with estimation of switching costs, and evaluation of current maintenance costs [17:49:36] Light but useful I think (though I haven't tried it, I think I get the basic idea). [17:49:59] superm401, see e.g. http://wmde.wmflabs.org/t/wikidata-developers/2014-03-04/ for Scrumbugz live [17:50:00] I think we can improve Scrumbugz just as easily as Phabricator. All of us pretty much know python [17:50:20] and I think getting the kinds of views awjr wants is easier in Scrumbugz than it is in Phabricator even, fwiw [17:50:29] I don't know about that, but I think more people here are willing to work on it then Java. [17:50:31] Would scrumbugz be an "all in" option or yet another alternative to Trello/Mingle/Greenhopper/Crystal Reports/MSDOS? [17:50:43] so I'd personally vote for Scrumbugz + status quo to be the other option to Phabricator whole-hog [17:50:45] marktraceur, to be more specific, what I would remove from the table are the other options still listed as "likely", and also scenarios of partial implementation of Phabricator e.g. keeping Bugzilla but not Gerrit while trying to convince the Mingle/Trello teams to do their tasks in the half-backed Phabricator............ [17:50:54] robla, I would be willing to look at switching our team from Trello if we went with that. [17:51:22] no, I would say that Scrumbugz would only be viable if everyone moved to it. I think one of the most important requirements is that we stop fragmentation accross teams [17:51:33] +1 milimetric [17:51:34] I think we'll see huge wins if we fulfill that requirement [17:51:34] robla, milimetric : agree on all in [17:51:36] I'd be sad with a (scrumbugz+bz) + (trello+bz) + (mingle+bz) + whatever-design-does situation [17:51:45] it'd be worse than status quo, in a way [17:51:45] ok...so it sounds like we have 3 major contenders then [17:51:49] superm401: I missed where Java comes into play [17:51:52] milimetric, so that brings up: "Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF." [17:51:55] What does that really mean? [17:52:09] andre__, any serious discussion needs a rant about Java [17:52:30] superm401: I think it means more fragmentation [17:52:31] andre__, I'm saying more people might work on Scrumbugz (Python) than Gerrit (Java). [17:52:35] ah [17:52:45] superm401: Keep in mind this is an early draft. But from the beginning we said we wouldn't force a tool on anyone [17:52:56] remember thought, scrumbugz implies bz which is Perl ;) [17:52:58] -t [17:53:04] superm401: in the way I'm thinking about it, Phabricator would be the ever approaching future....where at first we are permissive, and gradually get more annoying with people that haven't jumped on the bandwagon [17:53:08] I don't think force is the right word, but "prove superiority" would work :) [17:53:15] what superm401 asked, teams working on "unsupported" tools sounds [17:53:17] while i think it is a good idea to give teams the freedom to choose their tool, we really ought to do everything we can to prevent that from happening - that is finding the tool that eseentially meets everyone's needs. [17:53:33] awjr: or the largest subset possible [17:53:44] awjr: Phabricator is the tool that has come the closest to meeting everyone's needs so far [17:53:47] aye, i realize that may otherwise be a three legged unicorn ;) [17:53:48] there is no mythical tool, some teams may need to change their practices [17:53:54] awjr: yes, but there's going to be a transition period. there's no getting around that. [17:54:00] totally robla [17:54:13] there are community benefits to standardization that are greater than just benefits to teams [17:54:13] guillom, perhaps we could say we'll only do it if there's a net reduction in tools. E.g. Mingle could stay for now if people are stuck on it, but everyone has agreed (hypothetically) to drop Trello and scrumbugz. [17:54:17] So, let's try to sum this all up [17:54:21] honestly, I know people are kidding but it's a far cry from a totally doable implementation from a decently small set of requirements to a three-legged unicorn :) [17:54:36] i just bring it up because i dont want us to fall back on that and wind up picking a lesser tool - i dont expect that will happen, just voicing conern [17:54:56] I don't see what's so hard...you find a unicorn and chop off its leg. sheesh [17:55:02] hehe [17:55:03] touche [17:55:04] lol [17:55:08] +1 for community benefits [17:55:16] so practical [17:55:20] Alright, so [17:55:28] Future steps: [17:55:41] +1 on community benefiting from less/no fragmentation [17:56:12] awjr and other Agile/scrum experts to tell us everything that's wrong with Phabricator, and marktraceur and andre__ and I will help create tickets upstream [17:56:23] andre__: and I will simplify the RFC [17:56:32] andre__: and I will start an FAQ [17:56:44] thirded (?) +1 on community benefitting from standardisation [17:56:54] aye [17:56:58] alright [17:57:13] Am I missing any other big action item? [17:57:14] Would it make sense to do a test but read design review on Pholio to get the design team interested? [17:57:41] organize a 2 week trip to malta and we can all migrate at the same time to the unicorn :) [17:57:51] guillom: the analyzing current state with the amount of infra we support (bz, mingle, etc bots and all that) [17:57:53] Do we have any team that would be willing to test Phabricator in production? Would that even be desirable from a migration perspective or would it make things more difficult? [17:58:06] i'm happy to try phabricator early in the process [17:58:23] i would have to talk to my team, but there has been some strong interest in phabricator so flow could be a possibility [17:58:24] greg-g: Right. Thanks. I have no idea how to do that with any scientific rigor, but we'll try :) [17:58:34] simplified RFC has three options: 1. status quo (plus investment in bingle, bugello, etc, 2. status quo + migration to scrumbugz 3. throw everything out and move to Phabricator (accepting the possibility of a messy transition period), correct? [17:58:42] guillom: me neither, I think it's mostly a thumbnail sketch thing :) [17:58:42] (Multimedia team was also mentioned as a potential candidate in case they are interested) [17:59:06] robla: sounds about right [17:59:07] robla that is my understanding [17:59:19] +1 robla [17:59:28] +1 robla [17:59:29] robla: yeah, that sounds like the option we have (plus of course investment in Scrumbugz and or Phab too if considered needed) [17:59:34] *options [17:59:42] Another question before we finish: Is there interest in a semi-monthly IRC discussion about this? [17:59:51] andre__, I assume we would invest in whatever one we adopt to some degree, even if informal. [17:59:56] (or other frequency) [18:00:00] superm401, yeah [18:00:01] Growth might also be willing to try it early (haven't talked to anyone yet). [18:00:02] andre__: I'm definitely in favour of moving, not sure about tgr and gi11es yet [18:00:04] +1 [18:00:05] guillom: periodic yes....at least monthly [18:00:17] do we want to be explicit about everyone using the decided tool? [18:00:30] marktraceur, you are not sure about gi11es ? How come I am? ;) [18:00:44] qgil_: Maybe you've had a talk with him that I haven't, dunno [18:00:51] I think tgr has reservations, I'm all for it [18:00:53] tnegrin: I think we can give a far-out deadline after which everyone will have moved? [18:00:54] tnegrin: Yes. That sounds like a key point to me as well. [18:01:08] tnegrin: i think that we should be explicit that that is a goal but i do not think we can reasonably require that everyone use the same tool [18:01:51] awjr: If we cannot require it, we'll soon be in the same fragmentation situation that we're in now (unless phabricator really is a three-legged unicorn) [18:01:52] awjr: at least at first. over time, we'll have more leverage to shame people into doing it :-) [18:01:53] sure we can, we can just insert drop packets to anyone trying to connect to trello or mingle [18:01:55] We could require that everyone moves off Bugzilla (I think every team using another project management tool also has Bugzilla). [18:02:01] I suspect we will need a burn the ships orientation to make sure people migrate [18:02:02] That's not the whole thing, of course. [18:02:10] greg-g: Remind me never to become your enemy. [18:02:12] look if the tool is good enough, then we don't need to require it [18:02:15] guillom: :) [18:02:21] epriestley, thank you for joining us today! Not the first messy informative IRC meeting you have been to, probably. [18:02:22] people will see the benefit and *want* to use it [18:02:25] awjr: switching costs [18:02:43] oh man... [18:02:45] tnegrin we can do a lot to help mitigate that as an org though through support etc etc [18:02:53] awjr: totally [18:02:55] so, what about our extension developer community? [18:03:02] and eg pywikipediabot? [18:03:19] hmm [18:03:20] yeah, there are a lot of folks that are just straightup using github for instance [18:03:34] well, they have always been free to use the tools that they want. But yeah, some migrated to Bugzilla lately. [18:03:43] qgil_: No problem. And if anyone has further questions, you can find me in #phabricator here on FreeNode during daytime in California. [18:03:46] (or from Bugzilla to Github) [18:03:53] epriestley, thank you! [18:03:54] I assume we would no longer offer Bugzilla to third party devs if we're not using it for Wikimedia-deployed code. [18:03:54] Thanks again, epriestley :) [18:03:57] andre__: and were force migrated to git :) it's just something to think about, messaging/reasoning-wise [18:04:13] superm401: yeah, my assumption, too [18:04:14] But volunteers could still use GitHub for their own stuff, of course. [18:04:30] yes [18:04:31] superm401, what? [18:04:31] aude: do you know if the wikidata team would have any preference here? [18:04:46] qgil_, I mean like third party (non-deployed) extensions, and gadgets, bots, etc. [18:04:56] superm401, wait, wait, I don't see any reason to change the scope [18:05:22] Am I changing it? Those things can already be hosted anywhere. [18:05:22] superm401, any MediaWiki based project is welcome, because any MediaWiki based project can be eventually deployed in Wikimedia servers one day [18:05:36] qgil_, I'm not saying "deny them Phabricator". [18:05:42] Thats a rosy view ;) [18:05:42] I'm saying that some of them don't use any of the tools we're replacing. [18:05:49] qgil_: the point was shutting down their bz component and moving them to phab/whatever [18:05:58] qgil_: I think superm401 is talking about people who are already hosting stuff outside of our repos, and that would still be free to do so (although they would be encouraged to join the pack) [18:06:01] So it's silly to require them to suddenly adopt our new tool if they're currently suing BitBucket or GitHub. [18:06:08] Sorry, currently using [18:06:20] superm401, ah, ok, sorry [18:06:21] summary re this subtopic: might want to make sure we get at least some input from third-party devs who use bz/gerrit right now [18:06:36] heh +1 [18:06:47] and hopefully the tool will just be so good and convenient that the choice will be a no brainer [18:06:51] andre__: you probably have some contacts in that community from the latest migration? [18:07:17] Yes, for example https://bugzilla.wikimedia.org/show_bug.cgi?id=52692 for pywikibot [18:07:39] legoktm handled that mostly with valhallsw [18:07:43] ok [18:07:50] Alright, any last-minute words? [18:07:53] greg-g, yes, can someone make an action item to send a post about that to wikitech (third-party devs, non-deployed, etc.)? [18:08:23] guillom: andre__ ^^ ;) [18:08:27] #redirect [18:08:30] I volunteer andre__ :) [18:08:46] (but I don't mind helping write the email) [18:08:59] If that's all... [18:09:00] #action andre to get some input from third-party devs who use bz/gerrit right now [18:09:06] alright [18:09:07] Thank you all for coming [18:09:14] It's been incredibly helpful :) [18:09:18] thanks for hosting! [18:09:18] thanks much andre__ and guillom ! [18:09:20] Whou. That was pretty active! Thanks everybody! [18:09:22] Thank you! [18:09:27] thank you! [18:09:34] We'll follow up on the wiki and the lists [18:09:34] (and thanks epriestley) [18:09:38] thanks for hosting :) [18:09:45] And we'll be back on IRC in a couple weeks [18:09:56] im eager to find our unicorn [18:10:07] #endmeeting [18:10:08] Meeting ended Fri Mar 28 18:10:07 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [18:10:08] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-28-17.04.html [18:10:08] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-28-17.04.txt [18:10:08] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-28-17.04.wiki [18:10:09] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-03-28-17.04.log.html [18:10:10] In the meantime, if you have any questions / comments / unicorn treasure maps, please send them to andre__ and me [18:10:10] or if we've found it, embrace it :) [18:10:11] * greg-g hands awjr a carrot and superglue [18:10:17] :D [18:10:19] Ok, and now that the official office hours has finished, question: is Wikimedia Single Sign-On a possibility, or could it become even a requirement? That would make editors (and many more) happy. [18:10:23] * awjr glues carrot to his forehead [18:10:36] qgil_: I think it's a possibility [18:10:54] Phabricator can handle many different auth providers [18:11:03] I would love to make SSO work [18:11:04] And +1 on how much it would mean to our editors [18:11:22] ok, then that is a relatively simple selling point of PH [18:11:29] We'll have to do it ourselves, but it would be a game-changer for reporters imho [18:11:32] If we don't do a straight Phabricator -> Bugzilla email migration, we have the same problem we have now. [18:11:39] we need to actually test the permission system, guess we'll nee public bugs, read-only bugs and hidden bugs (for groups) [18:11:45] There can be multiple Wikimedia wiki accounts with the same email, and some have no email. [18:12:08] So we can't migrate easily migrate both auth sets to Phabricator. [18:12:09] superm401: we can use different auth providers at the same time [18:12:42] guillom, hmm, so migrate the Bugzilla email database, but add a "Login with MediaWiki.org"? [18:12:55] superm401: possibly. We'd have to think about it further. [18:12:56] wants stuff like "legal and ops can write, volunteers can read" [18:13:08] mutante, yep, should be able to test at http://fab.wmflabs.org/ . [18:13:17] yep, cool [18:13:37] woah woah what's that character: "f" [18:13:39] I've never seen one of those [18:13:40] hey, does anyone have the link to the security hangout ? or can they invite me in pls ? [18:13:42] mutante: yeah, let's create a dummy ops repo or something, with private tickets and the shenanigans [18:13:55] epriestley: :D [18:14:24] security presentation [18:14:25] guillom: sounds good, yes [18:14:27] uhm.. [18:14:35] epriestley, it was created as a secret instance, hence the distracting "f" [18:14:44] haha [18:15:01] Alright, thanks again, everyone :) See you around on the wiki, the lists and IRC. [18:15:05] bye [18:15:14] * guillom --> dinner now. [18:15:33] ..guess I've missed it [18:20:34] average: The security hangout is in ~2 hours. Poke csteipp for an invite [18:57:53] awww, missed office hours :( [18:59:00] greg-g: you would need to ask Lydia, but think folks have varying opinions [18:59:14] i don't know enough about phabricator (signed up on wmflabs, but dont' think my accoutn is approved) [19:03:23] aude: just checked the approvals queue. You should have access to fab.wmflabs.org [19:03:38] In the future we need to set this up to allow self-registration, naturally [19:04:20] StevenW: thanks [19:08:10] StevenW: I changed that setting earlier today, so now new accounts don't need to be manually approved. [19:08:21] guillom: sweet [19:31:37] average: No. You haven't missed it. It starts in ~ half an hour. [19:32:18] average: I see you have been invited already in the meantime.