Wiki Team Launchpad permissions (was Re: Proposal: Create product for each derivative's documentation)

[Jim Campbell]

On Mon, Apr 20, 2009 at 7:08 PM, Matthew East <mdke at ubuntu.com> wrote:

> Hi,
>
> On Tue, Apr 21, 2009 at 12:18 AM, Connor Imes <rocket2dmn at ubuntu.com>
> wrote:
> > That's fine by me, I am just trying to avoid being vague.  I share
> > Emma's concern with phrases like "a number" being a bit ambiguous.
> > Maybe we should just avoid addressing the issue of patch quantity
> > altogether as part of the "requirements" (or whatever you want to call
> > them).  This might approached with something like
> >    * "contributed patches that demonstrate a good and clear writing
> > style to the satisfaction of the reviewer."
>
> Well, that's even vaguer than saying "a number". :)
>
> But vague is good, in this instance. It's because we can easily get
> applicants who need a bit more guidance about style, and therefore go
> through a few patches before we are happy to grant them unrestricted
> access; or applicants who demonstrate it in a single awe-inspiring
> patch, or applicants who have already demonstrated it through
> contributions on the wiki and just need to show us that they are
> familiar with bzr and Launchpad, and so on. As Nathan said, it's just
> like asking how many packages you need to prepare before you are ready
> to become an MOTU: it's different in *every* case. Where something is
> different in every case, finding a common denominator becomes a bit of
> a waste of time, and you end up having more exceptions to the rule
> than followers.
>
> I genuinely think that introducing the page will grant a lot more
> clarity to our processes than currently exists, and that keeping the
> number of patches needed open is a more honest reflection of what we
> actually do.
>
> I've reworked the page a bit, so it's ready for any other comments:
>
> https://wiki.ubuntu.com/DocumentationTeam/Organisation
>
> I'm grateful that no one has yet pointed out that the name of the page
> doesn't comply with the style guide, *cough*. I'll rename it before it
> is finalized.
>
> One issue that hasn't been discussed to date is duration of membership.
>
> I think that in order to maintain a healthy ubuntu-doc-contributors
> team, we should have an expiry from the team of 6 months, with the
> ability for the member to auto-renew when the membership expires. That
> way, if they are still interested in contributing, they can renew, and
> if not, we get a more or less up to date view of who is interested. I
> think joining the ubuntu-core-doc or ubuntu-doc-wiki-admin team will
> demonstrate some continuity so the duration of that membership could
> be something like 2 years, again auto-renewable. Currently members of
> ubuntu-core-doc don't expire, but I think that a long-ish duration is
> quite healthy just so that members no longer interested in
> contributing can gracefully allow their membership to lapse.
>

Six months is one full release cycle, so I think that's ok. If someone has
joined the team, and hasn't started making contributions after six months .
. .  maybe they won't be making any contributions. In that sense, I don't
think that extending it to one year would make a noticeable difference in
how many new contributors we get.

I do think that it is best to keep doc-team membership a bit flexible in
terms of the guidelines, similar to how Ubuntu membership is handled. The
Ubuntu membership guidelines state, "A person who wants to become a member
should be engaged in a sustained level of contribution to the Ubuntu."
Granted, Ubuntu membership could come from forum work, loco-team work, code
contributions, QA, etc, but the point is that they don't try to narrow it
down too much. It comes down to team members giving their votes of approval,
and I think that has worked pretty well thus far.

Ok, I really need to get ready for work now. :)

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20090421/d5312efd/attachment.html>