On Fri, Oct 8, 2010 at 13:18, Bernie Innocenti <ber...@codewiz.org> wrote: > On Fri, 2010-10-08 at 09:24 +0200, Tomeu Vizoso wrote: >> If we are going to make an effort to revive a team, I would consider >> reviving the community team first so we can improve our chances of >> covering the dozens of other important positions we have vacant right >> now. > > True, but I've always had trouble figuring out what the coordinator of > the Community Team would actually do.
So, my view of coordinating a team is "just" doing some administrative-ish tasks that can help give identity to a group of people working on some specific area. Things like keeping a membership list, organizing meetings or making sure that all queries are followed up (even if it's a "we don't know"). Of course, someone who has taken those tasks will be in a good position to lead as well, but I don't see that as a requirement. > Community "management" is such an > ethereal thing that it's hard to frame it into a separate team > coordinator. I'm not sure as well of the convenience of having a "community manager", I'm not even sure communities can be "managed" in any sense close to the usual meaning of management. But I do believe that some communities do better than others in being a good collaboration place, and a community team would have as its goal to make sure that SLs becomes a better "place to work together". For example, the lack of an active administrator for the pootle backend has affected quite negatively my development work. It could be said that present-day SLs is a worst community than one that would have taken care that that role was fulfilled. How a community team could have helped there? This team would be actively checking that all important positions are covered, probably with backup positions and also that important processes are properly documented. When someone becomes MIA (or ideally, before that), the team would make sure that the issue of a critical position possibly becoming vacant would be in the top of the most important issues being discussed in the broad community. Another good example of what I would like to see more of in SLs is this thread from our colleagues at OLPC NZ: http://lists.laptop.org/pipermail/olpc-nz/2010-October/000850.html We rarely talk about how we could do better as a community, I have the impression that we have resigned ourselves to not do better than individual efforts. That really restricts what we can achieve. I see sister-organizations such as OLPC*, Waveplace or AC taking responsibility for areas that I think naturally would fall in SLs scope (and I'm very grateful for that, don't take me wrong). I'm not saying that SLs should strive to do *everything* sugar-related and that it should displace any other groups, just that SLs should strive to be the better place to do sugar stuff in a global context and right now other people are having to do that. I sure see some successes, the biggest one may be the technical infrastructure provided by your team, others may be periodic Sugar releases and being regularly packaged by one of the leading distros. But my idea of SLs from the start was certainly much more ambitious. > I do my own share of community management by inviting people I meet > (whether in person or electronically) to join the project at some level. > Being welcoming to newcomers is the duty of every Sugar Labs member. Sure, having a team doesn't mean that only the people in that team can do some specific things. I think the same could be said of development, translation, outreach, marketing, testing, etc. Several of the SLs members are doing many of them, I don't see any problem with it as long as people can have enough focus to make a good job without burning out. The idea of having teams is just to give some formal structure to a group of people that focus together in some specific area. > Mel and Frederick have led some initiatives to lower the barriers to > entry. Marco has been working on the same problem, from the development > perspective. There were really good recommendations in their blog posts. > If we formalize their work, it'd better be a horizontal role with enough > authority to make the necessary changes happen across all teams. Can you give more details about how do you envision that? Cheers, Tomeu > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep