Page MenuHomePhabricator

How to organize Wiki Release team monthly sprints and quarterly reviews
Closed, ResolvedPublic

Description

At Wikimania we agreed on organizing this program through monthly sprints with quarterly reviews.

For the monthly sprints Quim proposed to follow the model of the Engineering Community Team, but this might be a bit of an overkill just now (one meeting for planning the month, another one for showcasing the results). Maybe we can have one monthly meeting (hangout on air) where we all review the past sprint and we agree on the goals for the next one. Before the meeting, related tasks and workboards should be up to date, so we can skip the obvious reporting, and focus our time discussing problems and priorities.

Should we have own projects for each monthly sprint? Maybe, but let's start with a single project to check whether this is enough for now.

Then we will organize quarterly reviews in the same way that WMF teams organize them: a meeting inviting some stakeholders with minutes published.

The first monthly meeting could be scheduled by the end of September, taking into account the current transition of the team to this way of working (see T548). Quim will ask Praveena to schedule the quarterly reviews.

Details

Reference
fl549

Event Timeline

flimport raised the priority of this task from to High.Sep 12 2014, 1:46 AM
flimport set Reference to fl549.

qgil wrote on 2014-08-19 13:03:20 (UTC)

We also need to organize the workboard. Which columns do we need? For inspiration, see http://fab.wmflabs.org/project/board/31/

Mglaser wrote on 2014-08-28 23:21:45 (UTC)

Hm... I think the inspiration example is cool. I feel we have a few steps that could be useful (wording is not final, of course)

  • Needs more info: Ideas we have, that need elaboration. We have to ask people, gather information and such before we can actually start
  • Needs documentation: Things we did, but that were not documented properly. e.g. Meetings that need minutes
  • Needs decision: Tasks that seem useful but are beyone one of us to decide. E.g. What's the name of the user group
  • Ready to go: Just do it :)

On the other hand, we have another dimension. That is: release work and user group. This may be differentiated into more tracks. I don't know enough about Phabricator to tell the best way to organize this. Maybe colors? But they should also indicate priorities, right?

Palexis wrote on 2014-08-30 01:27:59 (UTC)

I like colors. It would be similar to how we have been differentiating between the release and user group responsibilities.

qgil wrote on 2014-08-30 20:41:36 (UTC)

I think less is more, at least to get started.

"Needs more info" & "Needs decision" == "Need discussion", right?

"Needs documentation" == "Doing" (if you consider that a task is not completed until it is documented.

If you have two dimensions (release work and user group) then the best thing is to have a project apart for the user group as soon as you have enough volume of tasks for that. Currently you still have three open tasks in total. Please create more, and we will find the best way to organize them.

Palexis wrote on 2014-08-31 00:42:05 (UTC)

Regarding: "...less is more, at least to get started"

Thanks. That is a very helpful, and certainly, a less stressful first approach. We have been focused on the getting the details right.

Palexis wrote on 2014-09-01 07:28:56 (UTC)

qgil wrote on 2014-09-01 07:36:23 (UTC)

Ok, you have done a very good progress over the weekend!

What about this:

  • Create a task named "September goals" or something along these lines and add as "Blocking Tasks" (see right navigation) those tasks that you are planning to complete during this month.
  • Try to do the same for quarterly and annual goals (those that will be checked in quarterly reviews and annual revisions of the contract).

There is no need to add all tasks to quarterly and annual reviews, only those bigger topics that will define how well are we progressing here.

As far as I know we haven't tried this process yet in Phabricator, although this is basically what we have on-wiki at https://www.mediawiki.org/wiki/Engineering_Community_Team. Do you want to try?

qgil wrote on 2014-09-01 07:38:17 (UTC)

Also, you have added a "Completed" task in the workboard. I'm still unsure about the usefulness of such column (which I had considered in other projects). The fact is, tasks completed just vanish from the workboard (unless you want to change the default filter and make them visible.

Anyway, details.

Palexis wrote on 2014-09-01 13:32:19 (UTC)

Thanks for the details - I am a big fan of details! :)

For now, and as I am trying to familiarize myself with Phabricator, can we keep the Completed column? I'll try to change the default filter and make it visible.

The column is useful in helping us monitor the user group tasks and sustain the motivation to help us push through the work - the work has a very short cycle with about four or five weeks remaining. When I am working with intense and short deadlines, being able to see the accomplishments helps tremendously.

Palexis wrote on 2014-09-01 13:38:20 (UTC)

Re: creating the above mentioned "September goals" and such

I'll give it a shot.

Palexis wrote on 2014-09-01 13:51:54 (UTC)

What is "Blocking Tasks"? How is it different from sub-tasks?

qgil wrote on 2014-09-02 07:11:04 (UTC)

They are the same. Well, actually not exactly the same:

  • All subtasks become blocking tasks.
  • Not all blocking tasks are subtasks.

Does this make sense?

Palexis wrote on 2014-09-02 11:58:12 (UTC)

Yes, and no. :)

It would make things clearer for me, if you can answer the following questions.

  • What is a blocking task?
  • What is the purpose or use of a blocking task?
  • In which situations would I be better off using blocking tasks instead of subtasks?

Thanks

robla wrote on 2014-09-02 16:37:25 (UTC)

A subtask can only have one parent task. However, a task/subtask can be blocked by many other tasks. Use subtasks when you want to group tasks together under a single task, and use blocking tasks when you want to define a sequence of tasks that need to be completed in order.

Palexis wrote on 2014-09-02 18:16:30 (UTC)

Perfect!

Palexis wrote on 2014-09-02 18:20:08 (UTC)

Thanks!

qgil wrote on 2014-09-04 15:24:21 (UTC)

Back to topic. I will not tell you how you should work but if you accept suggestions... We are already asking you to define annual goals, quarterly goals, and monthly goals. This alone has some risk of planning overhead. Now I see that you are defining weekly goals, and this has definitely a risk of creating unnecessary overhead and a too frantic dance of tasks.

If you need weekly goals to accomplish your objectives, fine. We-the-WMF are not requiring them.

qgil wrote on 2014-09-04 15:31:49 (UTC)

@Palexis, at T606 and similar weekly goals tasks you are defining the blocking tasks in the description. It is better to do it via "Edit Blocking Tasks" in the right navigation, because that is what makes a task dependent from another task.

Also, note that you don't need to type the title of a task. Just wrap the task number with curly brackets: T606 + { } = T606: Oct 29th Tech Talk: Intro to Wikidata. See the markup help for more interesting tricks.

Palexis wrote on 2014-09-04 16:37:09 (UTC)

Suggestions are good. :)

Okay. Reset.

Palexis wrote on 2014-09-04 18:18:42 (UTC)

User group's first quarter will be about done end of Sept/early Oct, the September Goals should suffice. Beyond that, we don't have much information to give you.

Release: you want September Goals, Quarter, and Annual Goals.

Phabricator kicked my butt today so I will have the RELEASE September Goals tomorrow. So when do you need the quarterly goals and annual goals?

qgil wrote on 2014-09-04 19:03:12 (UTC)

In T549#25, @Palexis wrote:

So when do you need the quarterly goals and annual goals?

Not before you have agreed them with the MediaWiki stakeholders. :)

The idea is that you can't plan soft term goals (e.g. September, October...) without longer term goals (Juny 2015), and vice versa. Monthly plans should be baby steps toward annual goals, and quarterly goals are good checkpoints. Then you can fine tune as you go.

Currently you have 17 tasks under "Doing". This might be true, but it looks suspicious. Are you really working on all those tasks simultaneously?

Also, in your workboard "Ready To Go" is at the right of "Doing". The idea is to list there the tasks that are not sitting in the backlog or under discussion anymore, the next candidates for "Doing". I will switch the position of both columns.

Regarding; "Currently you have 17 tasks under "Doing". This might be true, but it looks suspicious. Are you really working on all those tasks simultaneously?"

I would say, yes, within a month the release team is working on all of the tasks in the Doing column.

The parent tasks are general, ongoing work for the term of the respective work period. Sometimes they are discreet and clearly identifiable to one individual and a period of time; however, the majority of the time they overlap within a collaborative, team environment where multiple individuals work to produce an outcome with the deadline either being a scheduled release, event, or the contract end date. I agree that it is hard to believe that anyone is able to simultaneously work on all their responsibilities, but they can work consistently throughout their allotted time to achieve their objectives and goals.

When I first set up the tasks in Phab, I carried over the action items established with Greg so that the release team can meet the agreed upon goals. We are discovering differences in our ways of organizing. I am the alien from another geek world entering your geek world. :)

If you have time, maybe we can schedule a brief meeting to sort this out.

Palexis set Security to None.
Palexis added a subscriber: MarkAHershberger.

Sure I have time, just propose a date and time that suits to you.

I think it is useful for a team to set monthly goals that can be completed during that month. Many times these goals are milestones of longer term goals, which is fine and good. Sometimes it is just impossible to do that split. Fine as well, but these cases should probably be more the exception than the norm. Otherwise there is no easy way to measure performance and success at the end of the month, because 90% of the open tasks at the beginning of the month will be still open at the end.

Then you need to set priorities that make sense from the team point of view, but also from the individuals point of view. For instance, as of today, @MarkAHershberger owns 11 tasks with High priority, which is in my eyes reads as no real High priority at all, because in practice this is unfeasible. I'd rather see Mark with about 3 top priorities to focus right now , de-prioritizing all the rest.

Thanks, Quim.

I'll look at my calender and see what is available today, or tomorrow and then shoot you an email. If we can meet tomorrow, I should have a decent plan for a hearty discussion. :)

Markus is trying to get through the registration in Phabricator. Until then, which should be soon, Mark is the default person. If you prefer, I can have tasks unassigned and you can infer that they below to Markus.

They are all high priorities for the following reasons:

  1. T480: Agree and Document the Process to Include Security Fixes in MediaWiki Releases, T481: A single page describing the MediaWiki release checklist, and T492: Document the QA process for MediaWiki releases are recent tasks that you indicated as High (and the release team wants to complete by the end of the week).
  2. T364: How to organize Wiki Release team monthly sprints and quarterly reviews you set as High early in September when we first began using Phab.
  3. T393: MediaWiki Security and Maintenance Releases: 1.19.20, 1.22.12 and 1.23.5 Markus is scheduling another release by the end of the week.
  4. T399: USER GROUP: Buildup - Develop a Roadmap, T403: USER GROUP: Buildup - Initiate Process of Applying for Recognition, T404: USER GROUP: Understanding and Build Up an Ecosystem - Environmental Scan, T405: USER GROUP: Understanding and Build Up an Ecosystem - Compile List of Third Party Contacts, T407: USER GROUP: Work towards a Developer Community - Inititate a Developer Exchange, T408: USER GROUP: Finance and Fundraising - Research Structure/Methods and Available Grants, and T412: USER GROUP: September Goals are the user group tasks that will soon expire on October 7, 2014.

@Quim, is there anything else that needs to be done or discussed in order to close this task? Thanks.

I think we have agreed the way of working, but still needs to be documented somewhere in your pages at mediawiki.org.

It doesn't need to be anything extensive, just explain this dance of annual goals, monthly sprints and quarterly reviews for the release and the user group tracks.