Promoting new members

[Emma Jane]

On Tuesday 21 April 2009 5:33:39 am Matthew East wrote:
> On Tue, Apr 21, 2009 at 9:44 AM, Dougie Richardson
> <dougierichardson at ubuntu.com> wrote:
> 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

Actually what's really confusing is why you would want to become a member of 
that team.


> > 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.

It's common to see what you want to see as the problem, Matthew. What you are 
seeing is that "everyone else is doing it" and so you are no longer worried 
about the documentation team. Repeatedly people are "sent" to documentation 
when they very very new to Ubuntu as a way of getting their feet wet in 
contributions.

I could paste you the number of times that I've suggested something I'd like 
to work on and been told why it's a bad idea. So I just go back to playing on 
the Wiki and making screen casts on for other teams. If you, Matthew, can't 
figure out how to engage a published author with multiple years of DocBook and 
technical writing experience, you're doing it wrong. And if you can't figure 
out how to help a newbie learn how to edit a Wiki page (something we do a LOT 
of in the Drupal team at sprints, in IRC and via the mailing list), you're 
also doing it wrong.


> 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,

Neither of whom are members of "the team."

> 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.

Actually, what that discussion is showing me is that the core team assigns 
"commit" access on a feeling/flexibility/etc, and that being a member of that 
team is to be held in very high regard. To be honest I'm a bit surprised that 
no one is embarrassed by this. From the outside it shows a group of people who 
are inwardly focused, disinterested in working with new people and who will 
only grant permission to be a member of the elite to their buddies.


> 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.

Actually, identifying those pitfalls is exactly how you discourage people from 
participating (or in the case a study I'm currently reading, how you guarantee 
a child's failure at school). Have you heard of the ol' trick of sticking a 
pencil in your mouth while talking to force a smile? It works with leading 
volunteers as well.


> 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.

OpenSUSE manager, Zonker, actually recommends not having important discussions 
in a mailing list. Nothing ever gets done. He recommends putting them into a 
Wiki instead. Matthew, have you updated the Wiki to incorporate the 
suggestions I made? Or have you merely torn them apart on the mailing list? I 
still see words like, "a number", "significant" and "understanding." In fact it 
seems as though you /removed/ the "three patch" minimum that Connor and I 
talked about.


> > 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.

Why are you the only person who can do this, Matthew?


> > 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.

Of course the documentation team should be documented. Please don't put this 
on Dougie. You should be documenting your work without Dougie having to ask. 
If someone has to ask... see above re. you're doing it wrong.


> > 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.

OY! You just did snipe at him! Right there!


> > 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.

Any time he does you break it into a minutiae of inline comments that make it 
impossible to address the larger problem.


> 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.

You ignore the comments that you do get. Just this week Ben gave you comments 
and you told him to wait until it was sorted out. I have received private 
emails and I'm not even a "member of the team." People are telling you 
Matthew, you're just not listening.



regards,
emma