Promoting new members

Dougie Richardson dougierichardson at ubuntu.com
Tue Apr 21 17:48:04 UTC 2009


Hi Matthew,

2009/4/21 Matthew East <mdke at ubuntu.com>:
> 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

[snip]

I agree its not uncommon but realistically shouldn't documentation be
low hanging fruit? I can't speak for the other teams you mention but
the bugsquad drive for new volunteers - especially with hug days.

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

Thats not how it comes across Matthew, it seems very negative and
often seems directed at certain members.

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

I've intimated on several occasions a willingness to decrease your
workload in this area. What I said is true or at least it should be a
bigger area because as we've all said at various stages people use
Google first - so having the web up to date is prudent.

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

Yes and I've explored them but given how many have been put off by the
complexity of the tool chain then I think its prudent to document it.

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

The wiki covers how to get, edit, validate and submit a patch. It
doesn't cover the structure of the package, entities and their usage,
the libs folder, XSL templates, building web pages or PDF.

Granted I can find this out myself but if these were worth including
in the package then they should be explained.

I'm not implying some kind of deliberate obfuscation - if you were to
step back then we need that information. This is especially true of
comitting to the HUC page.

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

Did I say that? No. Matthew I've worked with you for a long time and
consider you a good friend but you seem convinced I'm a paranoid out
to get you which simply isn't the case.

xubuntu-docs branching is a perfect example, the consensus said no and
it happened any way. Why you think this is a dig at you is beyond me.

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

Yes that seems sensible and I'm happy to do it.

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

I didn't say this wasn't fruitful, I said it was concentrating effort
in a minor area. Focussing on getting more people joining in should be
our focus.

>>> 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 really don't feel the need to trawl the last few years to prove I
said these things, after this amount of time can it not be read that
if I submitted it, then I submitted it?

Regardless they are good ideas:
1. Create playbooks - wiki and system.
2. Pick a topic
3. Promote its hug day
4. Be available on IRC to assist

While I'm there, we need to consider taking a look at MOTU, their IRC
lessons are proving very popular and we could be doing the same.

I'll put these on the meeting wiki. After all I wouldn't want to not
have proof they were suggested ;-)

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

I've no objection to doing it, in fact I'm happy to, I just felt it
would carry more weight from you!

-- 
Regards,

Dougie Richardson
http://www.lynxworks.eu/
dougierichardson at ubuntu.com




More information about the ubuntu-doc mailing list