[maemo-community] Sprint meeting & process

From: Dave Neary dneary at maemo.org
Date: Wed Jun 17 16:33:34 EEST 2009

Andrew Flegg wrote:
> Following the earlier discussions[1], here's a plan for the next sprint meeting:
> Date:    Thursday, 18th June 2009; 13:30 UTC

Unfortunately, at this short notice I will not be available tomorrow - 
I've already committed to something out of the office.

I can give progress on my tasks from last month, and also describe what 
I expect to be my top priorities for the coming month, in this email, 

If anyone has any suggestions/criticisms/complaints/ideas about other 
things I should be doing, please shout.

> Pre-meeting actions:
>    * Post of status updates and conclusions on assigned tasks[2] to
>      this thread by 2009-06-18 12:00 UTC (90 mins before meeting)

Moderators and moderation for Brainstorm [1]: DONE
  	Moderators all informed, sent to Council, awaiting
	announcement, brainstorm site is open

Break down Summit into subtasks [2]: DONE
	See Summit planning page [3]. Current top priority is the call
	for content [4]. Nokia events will do much of the preparation of
	the site & parties.

Last month, I was expecting summit organisation to take a huge amount of 
time. Quim has informed me that Nokia Events will be taking care of 
getting the site ready, organising parties & events, etc. So all that we 
the community have to worry about is the content for the 2 community 
days, organising ourselves for the travel budget, and giving the 
requested feedback on merchandising ideas. And aside from the content, 
none of that really needs a lot of my time.

>    * Preparation of task URLs from backlog. Each URL should
>      point to a wiki page, Bugzilla issue or talk.maemo.org post.
>      It should contain a definitive issue and plan of how it will
>      be addressed. All tasks should be binary-completable; with
>      little to no ambiguity on whether it can be considered completed.
>      All tasks should be expected to be completed withtin the period;
>      if a task is too large, it should be split up.

The task I expect to spend most of my time on next month is this:
https://wiki.maemo.org/Task:Publishing_API_docs - this page needs to be 
updated now that we have a plan, and become a kind of project page for 
following the progress of the implementation.

I do not expect that we will have completed the entire task within the 
month, so I'd like to break it down a little for sprintable chunks:

* Proof of concept library.maemo.org install updating API docs from 
.debs: MUST

  * Get test machine with library.gnome.org and test Debian repository 
working (MUST)
  * Modify library.gnome.org to use .debs of docs rather than building 
.tar.gzs (SHOULD)
  * Ensure automatic updating on releases happens (COULD)

* Co-ordinate Maemo Summit call for content: This will be ongoing until 
September, I don't know how you want to put this in the sprint.

* Proof-read HIG  [6]: I want to co-ordinate a proof-reading of the HIG 
by native English speakers this month. This will be a "COULD" item for me.

> Proposed sprint process:
>    * Pre-meeting distribution of final task statuses, along with
>      whether it is complete.

Who will do this? It seems like a cumbersome issue for the person that 
does it, when it is more or less a copy & paste of part of the wiki page 
with "what's holding you up?"

>    * Fixed meeting date: first Tuesday of the calendar month at
>      13:30 UTC. The next meeting will be on Tuesday, 1st July.

Seems like a good idea. But that only gives us 2 weeks for this sprint. 
So even the SHOULD tasks have to be small this time.

>    * Status updates (in-place of daily stand-up meetings MUST be
>      sent to maemo-community on a daily basis. The subject should
>      be of the form "[STATUS] Some example task description".
>      Follow up statuses can be added to the thread for the first
>      report; indeed, this is preferrred.

I fear that this will reduce further the value of maemo-community. If 
one of the issues is that we're making sprint tasks too big (I suspect 
it might be), then status reports will either be "Nothing to report" or 
"Made some progress on the scrumdoggle" (that is, meaningless to knowing 
whether there are problems, blockages, how much progress, etc) You'll be 
adding 80 mails a month with mostly useless information to a mailing 
list that doesn't have that much mail beforehand.

What feels missing right now is any feedback on status reports that are 
made. I have yet to see anyone send an email saying "This task has been 
stuck in neutral for a couple of weeks - is there a problem? What's your 
next action on that? Are you stuck?" Or after a status report, follow up 
with me to say "there wasn't much detail in there - what exactly did you 
do?" or "You said in yesterday's status that you planned to send an 
email about the horncraffle but I didn't get it - is there a problem? 
What did you do instead?" or "I didn't see any status update for the 
past couple of days - is everything OK?"

I can see your point - make it easy for people to send status updates 
and ensure that status updates sent in one place are visible everywhere 
they should be. But this seems to me like it will make people less 
likely to send updates, rather than more likely.

>    * An RSS feed will be produced of all maemo-community posts
>      containing "[STATUS]" in their subject line. This will be embedded
>      within the sprint wiki page. (Action: Jaffa).
>    * Once created, the only change to be made to the wiki sprint
>      page is the change of the STATUS column from "Open" to
>      "In progress" and then "Complete" (once done) or "Closed" (if
>      abandonned).
> Hopefully this process will be lighter weight, and although there's
> still manual wiki page editing to be done if this process works out, a
> small workflow system can be developed to make it easier.
> Unfortunately, the fixed date will mean this period is only officially
> a couple of weeks long; but I had hoped to garner more feedback before
> running yet another behemoth meeting resulting in sub-optimal tasks.


[1] http://wiki.maemo.org/Task:Maemo_brainstorm
[2] http://wiki.maemo.org/Maemo_Summit_2009
[3] http://wiki.maemo.org/Maemo_Summit_2009/Organization
[4] http://wiki.maemo.org/Maemo_Summit_2009/Call_for_content_template
[5] https://wiki.maemo.org/Task:Publishing_API_docs
[6] https://bugs.maemo.org/show_bug.cgi?id=4405
maemo.org docsmaster
Email: dneary at maemo.org
Jabber: bolsh at jabber.org

More information about the maemo-community mailing list