Community practices proposal

[Israel Saeta Pérez]

Hello people!

I recently attended to a round table talk about building communities,
in the MozillaCamp08 in Barcelona, and picked up a bunch of ideas from
the Polish Mozilla Community that could be interesting for our team.


= Mentoring =

When somebody wants to join the documentation team, first he or she
has to start contrubuting for three months (just an example, could be
less or more time) before being officially considered part of the
team.

During this period, an existing member of the team acts as mentor,
reviewing his/her work, helping him/her to get used to the process of
reviewing new articles, following a style guide, looking for people to
complete missing documentation, etc.

After this period, each member of the documentation team votes to
decide if the candidate to member can oficially join the team or not.

This might look like an unneccessary barrier to collaborate with the
documentation team, but I think it really isn't since:
    1) The candidate (is supposed to) start contributing since the
first day, even without being a member of the doc team.
    2) People feel more comfortable in a new team if they got a
reference person to ask for guidance instead of a list of unknown
people.
    3) We ensure new members have learned the neccessary lessons like
target roles, style guide, etc. and they're really interested in being
part of the documentation team.


= @docs.plone.org email address =

When a new member finally joins the documentation team he/she gets an
address of the form "user@..." or similar.

This practice, surprisingly or not, could increase the interest of
some people to join the team and be proud of it exhibiting their
@docs.plone.org address.

I know that this would involve some burocracy but, if it's not too
much, it could be worth it.


= Regular meetings on the IRC =

Every week/month/whatever the members of the documentation team meet
on the IRC to talk about the past, current and future tasks and
projects. Before each meeting, every member writes down the list of
things he/she has done, what problems did he/she find and what will
he/she do next.

This previous work allows to keep the IRC meetings short enough (30
minutes), and provides an easy way to track what's everyone doing. The
IRC log is posted to a wiki-like webpage later.

Example:
 http://wiki.aviary.pl/Stand-up:2007-10-08


What do you think about these ideas? What other community practices do
you believe we could follow to increase our productivity and unity?


Best regards,
Israel Saeta

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
Plone-docs@...
https://lists.sourceforge.net/lists/listinfo/plone-docs

[vedaw]

I like this concept of mentoring. Where possible, we've tried to do this, I
think. For example, we recently had someone who wanted to work on
translating docs, and we referred them to Hector Velarde for guidance.
However, there isn't a real structure for how this happens, and I don't know
how well that mentoring process worked out.

I would like to suggest that we have one or two people guide new docs people
to documentation area best practices -- even I haven't read the "how to
contribute" documentation, and sometimes a quick introduction is the best
way to get people moving. I don't think posting a link and saying "read
this" is very useful. Point persons should also be responsible for finding
mentors for newcomers and for following up with mentors on progress. And, we
should record the names of newcomers and when they approached the docs team.

I wouldn't get too wrapped up in the time frame involved in terms of how
well new docs people contribute at first -- that introduces some overhead
that I'm not sure we're ready for (speaking personally). I think
instinctively, the docs team knows who is contributing and who is not, and
report-backs will make this more obvious. If mentors also report back how
their new charges are performing, I think this would become more
transparent.

I'm not entirely opposed to the email address idea, but it is a bit of
overhead that makes it hard for those of us who are strapped for time to
handle. We're having enough trouble getting content rules and mailing lists
set up to alert editors to incoming docs without adding this to the mix. I'd
like to table this one for now.

Agreed on the regular docs team meeting. I'd ideally like to see this at a
set date/ time, with flexibility for people in alternate time zones. In
those cases, we could accept email submissions for people to explain what
they've been working on, what they want to work on next, and what any
blockers might be. Or, we could alternate meeting times to make it easier to
get participation outside of the continental US. We'd just have to have a
European, Australian or other person take ownership of the meetings specific
to that window of time report back to the group at large.

And yes, on tracking meetings. This could happen on
openplans.org/projects/plone-documentation, though of course we should have
meeting minutes and not just the IRC extract.

Shall we discuss your ideas at the next meeting, with the objective of
assigning point persons, setting a meeting schedule, and identifying meeting
leaders in time zones that typically get neglected? I also think editors
need to come to the table with action items that can be accomplished before
the next meeting occurs.

Would anyone like to throw their names into the hat on any of these? I can
certainly help out as a point person, though my time is very limited.

Thanks for bringing these ideas, Israel! All good!

Cheers,

- Veda


On 10/26/08 3:53 PM, "Israel Saeta Pérez" <dukebody@...> wrote:

> Hello people!
>
> I recently attended to a round table talk about building communities,
> in the MozillaCamp08 in Barcelona, and picked up a bunch of ideas from
> the Polish Mozilla Community that could be interesting for our team.
>
>
> = Mentoring =
>
> When somebody wants to join the documentation team, first he or she
> has to start contrubuting for three months (just an example, could be
> less or more time) before being officially considered part of the
> team.
>
> During this period, an existing member of the team acts as mentor,
> reviewing his/her work, helping him/her to get used to the process of
> reviewing new articles, following a style guide, looking for people to
> complete missing documentation, etc.
>
> After this period, each member of the documentation team votes to
> decide if the candidate to member can oficially join the team or not.
>
> This might look like an unneccessary barrier to collaborate with the
> documentation team, but I think it really isn't since:
>     1) The candidate (is supposed to) start contributing since the
> first day, even without being a member of the doc team.
>     2) People feel more comfortable in a new team if they got a
> reference person to ask for guidance instead of a list of unknown
> people.
>     3) We ensure new members have learned the neccessary lessons like
> target roles, style guide, etc. and they're really interested in being
> part of the documentation team.
>
>
> = @docs.plone.org email address =
>
> When a new member finally joins the documentation team he/she gets an
> address of the form "user@..." or similar.
>
> This practice, surprisingly or not, could increase the interest of
> some people to join the team and be proud of it exhibiting their
> @docs.plone.org address.
>
> I know that this would involve some burocracy but, if it's not too
> much, it could be worth it.
>
>
> = Regular meetings on the IRC =
>
> Every week/month/whatever the members of the documentation team meet
> on the IRC to talk about the past, current and future tasks and
> projects. Before each meeting, every member writes down the list of
> things he/she has done, what problems did he/she find and what will
> he/she do next.
>
> This previous work allows to keep the IRC meetings short enough (30
> minutes), and provides an easy way to track what's everyone doing. The
> IRC log is posted to a wiki-like webpage later.
>
> Example:
>  http://wiki.aviary.pl/Stand-up:2007-10-08
>
>
> What do you think about these ideas? What other community practices do
> you believe we could follow to increase our productivity and unity?
>
>
> Best regards,
> Israel Saeta
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plone-docs mailing list
> Plone-docs@...
> https://lists.sourceforge.net/lists/listinfo/plone-docs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
Plone-docs@...
https://lists.sourceforge.net/lists/listinfo/plone-docs

[JoAnna Springsteen]

> = Mentoring =
>
> When somebody wants to join the documentation team, first he or she
> has to start contrubuting for three months (just an example, could be
> less or more time) before being officially considered part of the
> team.
>
> During this period, an existing member of the team acts as mentor,
> reviewing his/her work, helping him/her to get used to the process of
> reviewing new articles, following a style guide, looking for people to
> complete missing documentation, etc.
>
> After this period, each member of the documentation team votes to
> decide if the candidate to member can oficially join the team or not.
>
> This might look like an unneccessary barrier to collaborate with the
> documentation team, but I think it really isn't since:
>    1) The candidate (is supposed to) start contributing since the
> first day, even without being a member of the doc team.
>    2) People feel more comfortable in a new team if they got a
> reference person to ask for guidance instead of a list of unknown
> people.
>    3) We ensure new members have learned the neccessary lessons like
> target roles, style guide, etc. and they're really interested in being
> part of the documentation team.

Maybe it's too much responsibility, but I see editors doing this. Or
at least setting up mentorships. I'm a huge fan of mentors...I've been
a mentor before and it's a great relationship. I see the kind of bond
it builds and it's a wonderful thing.

> = @docs.plone.org email address =
>
> When a new member finally joins the documentation team he/she gets an
> address of the form "user@..." or similar.
>
> This practice, surprisingly or not, could increase the interest of
> some people to join the team and be proud of it exhibiting their
> @docs.plone.org address.
>
> I know that this would involve some burocracy but, if it's not too
> much, it could be worth it.

I could go either way on this. I think some highly coveted (though not
necessarily expensive) trinkets would do the trick as well. A tshirt
to wear at conferences, sprints, or other events? Buttons? ribbons?
something to display on your desk at work? Might have the same effect.
Once we get the new plone.org up, I intend to prominently display our
editors names. Maybe we can do something similar with consistent
contributors?

> = Regular meetings on the IRC =
>
> Every week/month/whatever the members of the documentation team meet
> on the IRC to talk about the past, current and future tasks and
> projects. Before each meeting, every member writes down the list of
> things he/she has done, what problems did he/she find and what will
> he/she do next.
>
> This previous work allows to keep the IRC meetings short enough (30
> minutes), and provides an easy way to track what's everyone doing. The
> IRC log is posted to a wiki-like webpage later.

Yup. Every three weeks for editors. No reason the rest of the doc team
can't attend. But yes we need to do a better job about regular
meetings. We'll do it agile style. (unless we really need to
brainstorm or hash out a big issue)
Actually, we need to schedule an editor meeting for next week anyway
so I'll get on that.


> What do you think about these ideas? What other community practices do
> you believe we could follow to increase our productivity and unity?

The doc list is followed by a lot of people. Most have strong
opinions. Very very few people actually chip in. We need people to
step up and follow through on things. How we do that is hard. The
group using sphinx for the API is a great example of how this can be
successful. I wish we had more people willing to work with the doc
team in this way. I think the biggest thing we need to do is keep
driving home the point the documentation is just as important as the
code. This takes some marketing within the community on our parts. My
suggestion is that when you do something doc related, even if it's for
a client and not plone.org, hype it up. Show it off. Blog about it.
Tweet about it. Talk about it in IRC.
I think having more doc only sprints will definitely help our unity as
a team. We just need to start planning!!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plone-docs mailing list
Plone-docs@...
https://lists.sourceforge.net/lists/listinfo/plone-docs