Promoting new members

[Matthew East]

On Tue, Apr 21, 2009 at 9:44 AM, Dougie Richardson
<dougierichardson at ubuntu.com> wrote:
>> The discussions recently about improving (and clarifying) our
>> processes are part of helping newcomers to the team to see how we work
>> in a transparent way, and hopefully show people that it is easy and
>> rewarding to contribute. There is a reason behind those sorts of
>> discussions, they are positive discussions, and they will lead to
>> improvements.
>
> How does the current proposal show the process is rewarding?
>
> These discussions are perhaps positive in regard to streamlining our
> structure but we are assuming that is going to bring more volunteers.
> I don't think it will and in any case the proposed structure isn't
> very different from the current one!

I agree, it isn't. The idea is to improve the way that it is
documented. Currently it's confusing as to how to become a member of
~ubuntu-core-doc and the wiki admin group, and improving our internal
documentation will resolve that. To the extent that that fact is
getting in the way of people contributing or taking their
contributions further, that will be an improvement. Since you've
complained elsewhere that our internal documentation is incomplete,
and the lack of defined criteria for commit access, I don't think you
really disagree with me there.

>> I don't think it's true at all to say that people are requesting to
>> join the team each week. While it may be true that people join the
>> ubuntu-doc-students team on a relatively regular basis, it is not
>> often that someone sends a few patches and can be considered to join
>> the ubuntu-core-doc team. Nathan and Connor have recently started the
>> process, and as far as I'm concerned they are contributing good
>> patches, but in the past 6 months I personally haven't seen that many
>> regular contributors of patches. Your email is entitled "Promoting new
>> members": did you have anyone in particular in mind? If so, perhaps
>> this is a good time to test drive the application process!
>
> You know I'm talking about people joining students and not applying to
> join the commit team? There can't be people to test your new process
> if we don't have new students joining.

Ok, so to refine your complaint, it is that people are joining the
students team, and then not taking things further by contributing. I
agree that this is a concern. But I don't think it is particularly
surprising in this community - it's incredibly common for people to
show some level of interest by joining a team, and then not taking it
further. To put this in perspective, the ~ubuntu-marketing team has
588 members, the ~ubuntu-art team has 153 members, and the bugsquad
has 1762 members. Obviously the amount of interest a team gets is
directly related to the type of activity it performs, the friendliness
of its internal documentation, and lots of other factors, but I'm very
confident that not all of those people are contributors to those teams
- many just express an interest in contributing, and then disappear -
that's not unique to the docteam.

>>> I for one am not happy working in this team at the moment
>>
>> I'm sorry to hear that, and I would like to do what I can to help, but
>> it's difficult for me to understand the reasons you are unhappy. Could
>> you explain them in more detail?
>
> 1. Ideas that are suggested are not met with improvement suggestions
> or discussions on workability but with a list of reasons why it won't
> work.

This is a bit of a generalisation. There have been a lot of ideas on
this list recently, and quite a few of them are getting discussed in a
positive way and will lead to changes (see for example the lack of
documentation for commit access, raised recently by Emma and Nathan,
and now getting addressed). Another recent example is the use of apt
links, now used in the system documentation and being implemented on
the wiki.

For my part (and I'm only one member of this team) I always try to
respond positively to suggestions, but where I see genuine pitfalls or
difficulties, I will always say so. I don't think that's a bad thing.
When an idea is proposed in any open environment, a discussion will
take place around that idea which should be able to identify whether
that idea is a good one or not, and whether it is achievable or not.
We need to be realists, and not every idea that could possibly come up
is going to be desirable, or possible. Plenty will be though.

> 2. Suggested alterations to the frontpage of HUC - worked on it and
> there's no change at all.

There will be... this is waiting on me to review and implement, and
things have been quite busy recently. Sorry for the slow response.

> 3. There are large areas of the team that only you understand and are
> not documented - such as the website integration.

That's not true. Building the website for final release is not a
"large area" of the team, and it's actually very straightforward (it's
basically just "make all" in the Makefile, push the files to the
help.ubuntu.com branch which the sysadmins sync with the server). I
haven't seen a need to document it given that I've always taken care
of this aspect of the work, but I certainly will do so if you think
it's helpful.

All other aspects of the toolchain that I'm aware of are fully
discoverable by anyone interested.

In fact, I think our processes are better documented now than they
ever have been, but having said that, given that we're on a bit of a
drive at the moment, please feel free to suggest things that you think
aren't documented, and if it is something that "only I understand",
then I'll do my best to take care of it.

> 4. Whenever I venture an opinion on the Wiki, well that's guaranteed a
> snipe from someone.

I'm sorry, I think you are overreacting - I haven't seen any evidence of this.

> 5. This doesn't feel like a meritocracy - I refrain from suggesting
> how it feels on the grounds that hyperbole should be saved for when
> you really need it.

That's pretty difficult to respond to as well, but again I can only
invite you to make concrete suggestions for improvements. If what you
are saying is that I boss the team around too much and am holding it
back, then say so, and make some proposals about how I should change
my behaviour or how the team could change so that it is not held back
by me.

>> If it's because you are seeing a lot of discussion about process on
>> the mailing list at the moment? I personally think that those
>> discussions are very positive, and will lead to improvements for new
>> and existing contributors to the team. It's also a very appropriate
>> time in the release cycle to be having those discussions.
>
> That's preposterous and frankly I'm insulted that you would think
> that. The problem I have with these sort of discussions is that they
> are focussing energy on a perceived problem rather than finding out
> what the issues are.

Yes, you're right that often these discussions are focused on a
perceived problem. It's us trying to guess what improvements should be
made to our internal documentation or processes. Ideally, we'd have
loads of feedback from newcomers to the team about what we are doing
wrong, things they found difficult to understand, or didn't agree
with, and we could evaluate that feedback and act on it. At the
moment, we don't have that feedback so we are making a reasonably
educated guess at what we can improve.

Let's try and get some feedback. I've already invited others reading
this thread to comment, and perhaps what we could do would be to take
advantage of Launchpad's "contact a team" feature to send a common
email to members of ubuntu-doc-students, to request feedback. Would
you be interested in helping with preparing a draft email along those
lines, perhaps on the wiki so that others can review easily and edit?

In the meantime, making a guess at where we can improve is not such a
bad thing - there is an objectively identifiable gap in our internal
documentation which we are addressing in the
DocumentationTeam/Organisation page, so I don't think that is a wasted
discussion at all.

>> If it's because there are few people committing to the branches at the
>> moment, well we're working on improving that. Other suggestions that
>> you have for attracting contributors are definitely very welcome.
>
> Are they? Really? I've suggested hug days and bug drives repeatedly
> but after no response, well banging your head on a brick wall is
> likely to cause headaches.

I don't recall those suggestions, but they sound like good ones. Can
you provide a link?

>> I think it's worth contacting people in the team who haven't been
>> heard from for a while to ask why they haven't contributed and whether
>> they would be interested in getting involved again. Would you
>> volunteer to do so?
>
> Yes but woud it not be best coming from you (who is for all intents
> and purposes the team leader)? Would that not show their value?

I don't think it matters who it comes from, and it was your idea so I
was just inviting you to get involved in it. But ok, I'll put
something together.

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF