[16:00:19] 6Team-Practices, 6Engineering-Community, 10Gerrit-Migration, 3ECT-August-2015, and 2 others: Goal: Organize a Gerrit Cleanup Day - https://phabricator.wikimedia.org/T88531#1414078 (10Aklapper) [16:28:58] is there a detailed description of how to set "speedy meetings"? [16:29:43] It's mentioned on a few pages but not expressly explained. I was looking to send something to my team. [16:46:09] dstrine: https://office.wikimedia.org/wiki/Scheduling_tips#General_best_practices [16:46:39] https://office.wikimedia.org/wiki/Scheduling_tips#General_best_practices [16:46:43] Heh :) [16:46:58] yay! ^ [16:47:32] (one canonical page, more than on person knows where it is) [16:53:14] ugh office wiki vs media wiki.. so I was searching media wiki and it also has a page on "How to run a meeting" with a lot of overlapping information [16:56:05] dstrine: Yup, I created the mw/tpg "how to run a mtg" before I found Scheduling Tips [16:56:19] although the focus of the two pages is a bit different [16:57:07] I think mw is the better home, because the advice applies to non-staff too [17:00:51] dstrine: The tpg page does link to the office page, which is how I got there this time [17:01:22] meeple27: do you have a m.o. for tracking Discovery quarterly goald in Phab? [17:02:03] meeple27: I'm checkign out https://phabricator.wikimedia.org/tag/discovery/... [17:02:33] kristenlans: Dan has been leading that effort. He has created a Product Epics column, which I believe will be used to hold epics-that-are-quarterly-goals [17:02:57] meeple27: 10-4, that's what I assumed from looking at the board [17:03:34] the thinking (I'm not convinced) is that we should be able to have goal tasks which are parents of epic/story tasks which are parents of task/tasks, and thus everything we do should relate to a goal [17:04:16] meeple27: which part are you not convinced about? :-) [17:04:53] I tend to find that a) some necessary work doesn't relate to quarterly goal(s), and b) work in general doesn't fall nicely into hierarchical buckets [17:05:57] I'm optimistic that it will be "close enough" to work, even if it slightly offends my aesthetic sense [17:16:09] meeple27: and kristenlans: I don't understand the disconnect between quarterly goals and backlog epics, and tasks. If you have a properly groomed backlog, your goals should come from the backlog or they are added to the backlog as epics and eventualy broken down. [17:17:33] Goals rarely arise out of the backlog, and even if they do, when a team is only allowed ONE goal per quarter, it is unlikely that all work will fit into that [17:24:54] meeple27: Epics should not be parents of Stories, unless you intend to have a hierarchical backlog [17:25:09] (warming up for Kristen's meeting) [17:25:30] for VE, we are doing two things; grouping all of the tasks into different columns in one project [17:25:46] and also putting the goals in and then liking the tasks to the goals via the "blocked by" relationship [17:25:58] these are intended to be two independent sets of groupings [17:26:02] jaufrecht: I think Epics should be parents of stories even in heterogeneous. Exploded and shaved stories can still be subtasks of epics [17:26:10] and then we'll measure and see how much they overlap. [17:27:08] meeple27: I think that that parent-child relationship is only safe for historical tracking. I'm concerned that, combined with an Epics column, [17:27:26] it means that you have two different backlogs, one at the Epic level and one at the Story level, and they get out of sync [17:28:01] I agree that the epic column can be problematic [17:42:44] 6Team-Practices, 6Engineering-Community, 10Gerrit-Migration, 3ECT-August-2015, and 2 others: Goal: Organize a Gerrit Cleanup Day - https://phabricator.wikimedia.org/T88531#1414500 (10Dzahn) >>! In T88531#1149404, @scfc wrote: > The problem AFAICS isn't that the "wrong" changes are reviewed, but that not en... [18:03:18] jaufrecht: are you joining the meeting i invited you ti? [19:21:14] TPG'ers, I'm wondering about our use of epic tags [19:21:42] I'm following this wiki on phab project creation: https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects [19:22:25] TPG boards categorize epics as "Tags" but I wonder if they should be (and would be empowered this way) called "Umbrellas" [19:25:34] I chatted some with Kristen, and might reach out to Andre. awjr ggellerman_____ jaufrecht meeple27 dstrine thoughts? [19:26:50] Hmm, so far umbrella is more something like "VisualEditor" or "MediaWiki Core" which consists of several code projects [19:27:13] while tags are totally cross-project, like "accessibility" or "epic". To me at least, so far. :) [19:27:37] I think we are up in the air about any groupings above the Story level [19:28:04] we have consensus that a big enough Story is an Epic, but that's distinct from "how should we group/categorize/filter Stories?" [19:28:38] and the answer to that question is some blend of using projects as tags, using Epics as parents, using projectcolumns, and dunno what else. [19:29:04] not having a project mgmt background I always thought that workboards are kind of task progress tracking / swim lane thingies. So I was confused to see Epics on some workboards as a column. [19:29:26] We can express parent/child relations via "Blocked By" and such, between tasks. But that would not be visible on workboards... [19:31:14] I think the solution is to work backwards from "why are we grouping stories?" [19:34:00] jaufrecht: that's where I got to as well after the meeting today. [19:35:04] what decisions did you make? [19:38:46] jaufrecht: I'm gonna punt that one to mbinder :-) [19:40:58] jaufrecht: kristenlans ha, we basically came full circle. The team POs want to tie Q1 goals to epics to give Product (and above) a way to look at the boards at a high level [19:41:12] at this point, at least for this quarter, I think that is a foregone conclusion [19:41:23] now we are at the mercy of phab [19:41:48] really, this particular conversation we're having now just started because I was making my first board, in service of the teams that want to follow this path [19:41:57] and I didn't want to anger the phab gods [19:43:14] this page (https://www.mediawiki.org/wiki/Phabricator/Creating_and_renaming_projects#Type_of_project) gave me the idea for using "Umbrella" because of the concerns we raised in the last meeting about tags in phab falling off over time. [19:44:02] there is mention of some automation using the "global Herald rule" but I haven't been able to dig up more info for what that actually means [19:44:43] andre__: can you clarify what that means? [19:44:55] I suspect that if I can get some better burnups working, a lot of this will get clarified quickly [19:45:15] mbinder, what exactly? :) [19:45:24] andre__: global Herald rule [19:45:30] because the burnup consolidates these questions: what are you doing, and what after that, and what after that, and when will this all be done? [19:45:33] mbinder, ah. let me check [19:45:50] and all of these arrangements in Phab are just different paths to answer that question [19:46:02] jaufrecht: I can appreciate that. Do you feel it makes epics redundant? [19:46:35] * andre__ fixes the docs [19:46:55] I think any of the different approaches we've been discussion could contribute to answering; using burnups will help clarify which approaches are most useful given the combination of Phab limitations, per-team special conditions, and basic conceptual models of our work planning. [19:48:45] andre__: the link to global Herald rule on the doc goes to a 404 Phab page [19:49:09] mbinder, I'm fixing that right now [19:50:01] mbinder: Please reload the page and try again. :) [19:51:39] andre__: thanks. I'm still not totally clear on the Herald function. The thought I had was that maybe it could be used to automatically (or force) assign a task to an epic, which would mean that the epic would have to be an Umbrella [19:52:11] mbinder, what is "an epic" in this context? [19:52:21] a Phabricator project? a Phabricator workboard column? [19:52:57] "Umbrella" is a type of project. And an "epic" project exists, with the project type "tag". [19:53:06] andre__: it is a quarterly goal that represents a category of stories/tasks. The epics will be on their own, separate-from-the-tasks workboard. [19:53:25] andre__: yea, I saw that TPG uses epics that way and wondered if that was in fact correct [19:53:26] so you mean "a task" when you say "an epic"? [19:53:57] well, no, in the sense that the epics in this case are not part of a workflow, but yes in the sense that they are cards on a board [19:54:10] a card on a board is a task. [19:54:13] ok [19:54:29] at least in a Phabricator Maniphest workboard, it always is. :) [19:54:48] so I'm not sure how to interpret the question above now [19:54:54] right, I think there is some confusion about "task" in english and "task" in phablish [19:55:05] when you wrote " maybe it could be used to automatically (or force) assign a task to an epic, which would mean that the epic would have to be an Umbrella" [19:55:17] yeah, I'm pretty much stuck in Phab terms, sorry :) [19:55:28] I think, for now, we will use the tag "epic" and see if it works [19:55:46] thanks [19:55:50] mbinder, I just wonder which "automatic filters" you see. Because to apply a filter you need criteria [19:56:17] ah, alright, no problem [19:56:36] (and the available options in Herald are linked from the central Phabricator Help page) [19:56:38] yea, I think many of us are used to other tools, like Trello or JIRA, where the "forcing" is done more visually than anything. Phab doesn't give many details about a task unless it is opened [19:57:00] yeah, that's true - there's an open upstream task about customizing the display of cards on workboards [19:57:15] so the "forcing" is done when you see that a card is uncategorized into an epic, simply because it seems naked [19:57:20] only details you get is task summary, assignee, points and priority [19:57:25] thanks again [19:57:27] np [19:57:50] happy to help! (and please feel encouraged to ping me more often on such stuff when you think I could provide some info :) [19:58:24] 1. Epics are (almost never) cross-project [19:59:31] 2. A possible alternative to the Epic tag for quarterly goal tracking is the Goal type of project [20:00:08] 3. Grouping stories into a phab task (aka epic/saga) is something I would almost never do. I'm all about splitting stories. [20:00:29] (does 1. refers to the "epic" tag in Phab being a "tag", which is defined as cross-project? Wondering if I should comment on this or whether I'd just add noise) [20:01:28] No this is helpful. Frankly, I think the noise is mostly due to terminology being tossed around between process styles, tools, and english [20:01:39] alright, regarding 1.: "cross-project" refers to the tag itself ("accessibility" is something across all projects), not to any of the tasks being associated to that tag ("this specific accessibility task is cross-project"). That might be the misunderstanding here [20:02:11] these are "Types of Projects". These are not "Types of tasks per project". :) [20:02:19] andre__: #1 was somewhat in response to you. I don't think it's a problem to have an Epic tag, because it's like the "easy" tag. Associating a task with those projects doesn't suddenly make that task a cross-project task, but is has a shared meaning across the org (hopefully) [20:02:38] meeple27, it's never meant to make any task a cross-project task. [20:02:44] the project itself is cross-project. [20:02:47] yes, that makes sense. I misunderstood [20:02:56] or the "tag" itself is cross-project, probably better [20:03:53] and yes, "an epic" is a task, which is big (for some definition of big), and which may or may not say EPIC in the title, and may or may not have the Epic tag associated with it [20:04:18] in Bugzilla there the primary org structure were products (like VisualEditor) and (sub-)components. And a second org level were (pre-defined) keywords, like "accessibility" [20:05:09] meeple27, yeah, I've seen that. And I'm wondering how much I'm bothered that there are several concepts to mark Epics, one using prefixes and one using tags, as I'm not sure who would ever try to e.g. "search for all open epic tasks" [20:05:41] based on the email thread I started, it seemed like the epic tag is epically helpful for some people, and completely useless for others [20:05:56] I saw no consensus toward forcing its use, nor of getting rid of it [20:06:11] meeple27, Bugzilla was already messy, e.g. people used a "tracking" keyword but people also marked tracking tasks as blocking the meta-tracking bug T4007. So **A LOT** of information was duplicated by people who wanted to categorize tasks for the sake of categorizing, without being aware that one categorization already existed. [20:07:13] so that's my background and why I sometimes might come across as concerned or "but why this way if there is already another way?". [20:07:31] Doesn't it make sense to track quarterly goals using the Goal project rather than (or in addition to) the Epic project? [20:07:32] but I don't have any project mgmt or agile/scrum/sprint background so I am always curious and pretty happy to learn more about team needs [20:07:57] right. I prefer to have some level of standardization, although only when it makes sense [20:08:45] +1 [20:09:30] meeple27, the problem is agreeing on the "when it makes sense" part. Not necessarily between us, but [20:09:39] sometimes between us :) but yeah [20:09:40] there might be folks in our community who love categorizing anything and everything for the sake of categorizing. Welcome to Wikimedia. ;) [20:10:36] I pretty often ask "But why?" in tasks, e.g. a request to "Create a tag in Phabricator to mark all software license issue tasks" or such [20:11:11] because every added project/tag might create expectations for Phab users that the list of tasks in that project/tag is reasonibly complete [20:11:34] but to have a reasonibly complete list, people need to be aware of existing projects/tags, and need to add these projects/tags to tasks when appropriate [20:11:41] and I've seen how this has failed in Mozilla Bugzilla. [20:12:01] they have 600 keywords now, and nobody adds these keywords/tags to bug reports anymore because nobody can memorize them. [20:12:23] ...and that might be one of my fears and reasons for some reluctance sometimes. [20:12:30] * andre__ ends his monologue [20:14:17] yeah, it's a tough line to walk, but generally I appreciate minimalism in these things [20:14:53] +1 [20:15:14] yea, I especially appreciate the use of Epics as a process component, rather than a tag. I may revisit with the team POs and see if Phab Goals aren't more applicable. Seems like we are trying to force Epics into Phab. [20:16:59] andre__: Are there examples of existing Goal projects? My phab-fu is failing me in finding them [20:17:42] nvr mind. found it [20:17:53] https://phabricator.wikimedia.org/project/query/all/ is your friend [20:18:16] or https://www.mediawiki.org/wiki/Phabricator/Projects also lists stuff by project type [20:18:19] right. I always forget that phab has (at least) 4 different advanced searches, all of which have completely different options [20:18:27] 6 goals in the system so far [20:18:40] are you going to be ok if there are suddenly 50? [20:18:55] (Looking back, I'm still not convinced if introducing "goals" made sense compared to normal projects) [20:19:10] if these 50 goal projects make sense I don't have a problem with that ;) [20:19:45] I'm thinking that each vertical is likely to have 1-10 quarterly goals [20:20:17] oh, but that doesn't make sense [20:20:46] i guess each one would create a Vertical-Q4-Goals goal type, and then each of its quarterly goals would be a task (formerly epic) associated with that project [20:20:57] not sure that helps anything (but then neither does epic from my perspective) [20:20:58] sigh [20:21:05] back to pondering mode [20:21:31] :) [20:26:54] ha, thanks guys, this is illuminating, though I dunno if goals are better than epics now. [20:27:08] perhaps jaufrecht's charts will save us all [20:27:57] * andre__ can imagine to discuss this for hours while having some Mexican beers [20:39:40] VE is going to experiment with using Goal tags [20:42:53] The trap with workflow planning planning is that the only way to collect enough information to know what works is to try and fail. This is the same as any other software, with two exceptions: 1) the use cases tend to be much more complex (and boring), and 2) the "meta" nature of the tasks gets super-confusing [20:43:18] the key must be to balance collection of new information with adequate consumption of Mexican beer [20:43:48] kristenlans: https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey/Guidance_for_facilitators [20:45:22] mbinder: https://phabricator.wikimedia.org/T103565 [20:55:26] dstrine: https://office.wikimedia.org/wiki/Health_check_survey_results