m (→How can we get more people contributing to the MeeGo project?) |
(→How can we make the community office meetings more productive / useful?) |
||
| Line 7: | Line 7: | ||
* Due to conflicts with my day job, I have only been able to attend 2 meetings but want to attend more. I would like to see a unique approach taken to meetings, where they could possibly run 24 hours with handoff of moderation between coordinators in different timezones. This could be challenging but still possible I think.--[[User:Texrat|Texrat]] 18:28, 2 December 2010 (UTC) | * Due to conflicts with my day job, I have only been able to attend 2 meetings but want to attend more. I would like to see a unique approach taken to meetings, where they could possibly run 24 hours with handoff of moderation between coordinators in different timezones. This could be challenging but still possible I think.--[[User:Texrat|Texrat]] 18:28, 2 December 2010 (UTC) | ||
* We need to focus more on root cause issues during meetings so has to have greater impact. Too often it's easy to get bogged down on symptoms rather than causes. One specific example relevant to the marketing bullet point: many of us have asked for clarification on branding/identity issues with no response and/or no resolution. We need the owners of activities to be present so that root cause issues can be properly addressed, resolved and communicated. --[[User:Texrat|Texrat]] 18:28, 2 December 2010 (UTC) | * We need to focus more on root cause issues during meetings so has to have greater impact. Too often it's easy to get bogged down on symptoms rather than causes. One specific example relevant to the marketing bullet point: many of us have asked for clarification on branding/identity issues with no response and/or no resolution. We need the owners of activities to be present so that root cause issues can be properly addressed, resolved and communicated. --[[User:Texrat|Texrat]] 18:28, 2 December 2010 (UTC) | ||
| - | * If we want to use these meetings to get new and current contributors involved, then it is better to escape from the "meeting" concept (several topics, decisions, minutes, end of meeting at 60 mins...) and have only one topic for the whole session, let participation flow with soft facilitation, make sure the right people related to the topic will attend, stay as long as there is stuff and willingness to discuss... Also the role of Dawn and myself should be minimized ( | + | * If we want to use these meetings to get new and current contributors involved, then it is better to escape from the "meeting" concept (several topics, decisions, minutes, end of meeting at 60 mins...) and have only one topic for the whole session, let participation flow with soft facilitation, make sure the right people related to the topic will attend, stay as long as there is stuff and willingness to discuss... Also the role of Dawn and myself should be minimized (unless the topic of the day is something we happen to drive).--[[User:Qgil|Qgil]] 21:23, 2 December 2010 (UTC) |
| + | * In general, real time meetings should be used sparingly in distributed communities. The meeting time coincides with either bedtime, training or dinner time for me (21h French time) so it's never easy for me to attend. I imagine others further East are having even more trouble. Texrat mentions that we need to focus on root causes rather than symptoms - it seems like the community office meetings are treating a symptom ("Not getting enough information on in-progress tasks") rather than the root cause (why aren't we getting more information?). --[[User:Dneary|Dneary]] 13:50, 3 December 2010 (UTC) | ||
| + | * It might be worthwhile restating assumptions: My belief was that the community office, and all the infrastructure & overhead created around it, was created to help the community to get stuff done (where community = everyone involved in MeeGo), and to avoid a situation where only Nokia, Intel or Linux Foundation people could get stuff done. If that's the case, the getting information about in-progress tasks is only part of the solution - in principle, you get information to identify opportunities to participate and spread the load around. But if those opportunities aren't being created, then the information itself is not very useful. --[[User:Dneary|Dneary]] 13:50, 3 December 2010 (UTC) | ||
| + | * Listing unclaimed tasks in a wiki page has not been productive so far. People do not feel empowered to claim them, and many of the tasks listed either require some kind of special access, are waiting for a decision to proceed, or are quite big, vague & scary for one person to take on. Some suggestions for improving this might be: --[[User:Dneary|Dneary]] 13:50, 3 December 2010 (UTC) | ||
| + | ** Use Bugzilla to track infrastructure, marketing & outreach tasks, and get people assigned tasks in the habit of using it | ||
| + | ** Invite people individually to do stuff that you know are up to the task, and who communicate well what they're doing, and will include others along the way - personal invitations are infinitely more effective that asking people to volunteer. | ||
| + | ** Concentrate on making tasks a bit better defined, with a clear "win" result - make it easy for volunteers to have lots of small wins & mark things as "DONE" even if it means spending more time planning a task you won't actually do yourself. | ||
* Add your idea / comments here (with signature / timestamp) | * Add your idea / comments here (with signature / timestamp) | ||
Reminder: Community Office Goals for 2011