On Fri, Oct 8, 2010 at 13:18, Bernie Innocenti <bernie at 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/>>>