Changes to the meeting structure

Simon Steinbeiss simon at
Thu Sep 3 22:19:11 UTC 2015

Hey Pasi,

Thanks for the initiative and writeup. Making meetings more efficient is
definitely worthwhile!

On Thu, Sep 3, 2015 at 11:51 PM Pasi Lallinaho <pasi at>

> 1) Stop running the "Team updates" section
> Pasting the updates in a meeting means more work (through having to
> memorize/note down items) for contributors. It also means that those who
> can't attend the meeting (which means many people per meeting), can't
> paste the updates unless somebody does this for them.
> Since we now have a timeline tab [2] in the tracker, most of these
> updates can be seen live.

This absolutely makes sense to me. I've fallen in love with the new tracker
almost at first site and I think it should take a more prominent place even
on our website, because it is a one-stop-shop for outsiders to understand
what is "currently going on" in the team. (Even if the titles of the
workitems aren't self-explanatory, the tracker brings them together
meaningfully and allows people to follow the links to further information
as found on launchpad blueprints.)

> The only real change in action contributors would need to take would
> apply to work items. Practically this means that everything that could
> be worth mentioning for people outside the team - or added in the
> release notes - should be in the blueprints. Doing the updates like this
> also improves their findability. As I see it, this isn't much different
> from what we currently do, or at least what I try to do.


> Finally, the updates that aren't worth/important enough to add to the
> blueprints could still be shared in the meeting, thus...
> 2) Rename the "Announcements" section to "Updates and Announcements"
> This is just semantics, but it should be done to avoid confusion and be
> more accurate.

I would agree that this is a tiny change. I just hope people won't
unintentionally use it like the Team Updates section ;)

> I'm not the one who approves or disapproves the notion, but please do
> send feedback. This way we can likely vote about the changes around the
> next meeting.

Agreed, this should be voted on by the whole team at the next meeting.

To be frank, I haven't taken part in many other team's meetings, so I don't
know whether there is something we could learn or benefit from. But if any
of you are in team meetings that have e.g. a structure you consider
especially constructive please open a new thread on that so we can discuss
it. (Not saying we should throw our meeting structure out the window, but
since we're already on the subject...)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the xubuntu-devel mailing list