incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: AOO volunteers: essential skills and tasks
Date Wed, 24 Oct 2012 16:55:17 GMT
+1 Anything is better than nothing !!! and afterwards it can be improved.

jan

On 24 October 2012 18:49, Kay Schenk <kay.schenk@gmail.com> wrote:

>
>
> On 10/24/2012 09:40 AM, Rob Weir wrote:
>
>> On Wed, Oct 24, 2012 at 12:30 PM, jan iversen <jancasacondor@gmail.com>
>> wrote:
>>
>>> After a day of work, maybe I should elaborate on what I mean:
>>>
>>> Having read your documents in detail, which I really find SUPER, I see
>>> one
>>> challenge:
>>>
>>> "old" people in the mailing list pretty much knows who is working on
>>> (sort
>>> of responsible for) a given part, so they have no problems with
>>> "proposals"
>>> since they know who to approach, and the JFDI methods works well.
>>>
>>> new volunteers who wants to follow what happens and do a little here and
>>> there, will typically not make [proposals] but do JFDI on the wiki, and
>>> otherwise look for questions.
>>>
>>> The last part, those who want to be integrated and help move things, do
>>> have a slight problem:
>>> [proposals] might not even be responded to, especially if they fall in
>>> one
>>> of two catagories:
>>> - this is something we have discussed before
>>> - somebody is working on the theme
>>> JFDI method might be even worse, because you spent hours doing something
>>> sent it off to a committer and zero....
>>>
>>>
>> This is also a possible conflict between two new volunteers, or even
>> two "old" volunteers.  If you go off and work on something for a month
>> without telling anyone, then you risk that someone old or new does the
>> same thing, or similar.
>>
>> That is a point worth mentioning, that for larger jobs, you might want
>> to mention it on the list, not because it is controversial, but just
>> for coordination purposes, so others are aware.  Maybe they even offer
>> to help or give some helpful ideas.
>>
>> I can include these ideas in the text.
>>
>>  I believe in both methods, but I really believe that JFDI should be
>>> AFJFDI
>>> (asf first if anyone is working on it), and then do it. The proposal part
>>> is a bit harder, and maybe your document should state "wait with
>>> proposals
>>> until you are integrated in the commnity".
>>>
>>>
>> Certainly for larger tasks, this makes sense.  But if it is a quick
>> operation then JFDI works.  I suppose it depends on the
>> time-to-JFDI/time-to-post-and-**wait-72-hours ratio.
>>
>> For new volunteers they don't have access to SVN, so everything they
>> do is essentially RTC.  So submitting their patches is essentially
>> like making a proposal.   But the same considerations apply.  It might
>> make sense to float the idea first before investing a lot of time in
>> the work.
>>
>>  once again, your document are SUPER...the rest is just my experience.
>>> jan.
>>>
>>> On 24 October 2012 10:09, jan iversen <jancasacondor@gmail.com> wrote:
>>>
>>>  +1, that was something I could really have used some weeks ago :-)
>>>>
>>>> Maybe a word about "active volunteers" might not be harmful (I think I
>>>> am
>>>> in that state now)
>>>>
>>>> Jan I.
>>>>
>>>>
>>>> On 23 October 2012 23:30, Rob Weir <robweir@apache.org> wrote:
>>>>
>>>>  On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir <robweir@apache.org> wrote:
>>>>>
>>>>>> I am thinking about what new project volunteers need to get started.
>>>>>> Obviously there are area-specific things.  For example, developers
>>>>>> need to know how to download and build.  Translation volunteers need
>>>>>> to understand Pootle, etc.  But there are also some basic things
that
>>>>>> all volunteers should probably do.
>>>>>>
>>>>>> Although we have all of this information (or at least most of it)
on
>>>>>> the website or wikis or mailing list archives, it is scattered all
>>>>>> over the place.  I think it would be good if we could collect this
>>>>>> information (or at least links to this information) into one place
and
>>>>>> put a linear order behind it, a step of specific steps we want new
>>>>>> volunteers to take.
>>>>>>
>>>>>> Now, I can hear the objections already -- you can't tell volunteers
>>>>>> what to do.  That is why they are volunteers.  You can't regiment
>>>>>> them, etc.  This is true.  But at the scale we need to operate at
--
>>>>>> I'm aiming to attract dozens of new volunteers on the project by
the
>>>>>> end of the year -- we need some structure.  So what can we do to
make
>>>>>> their first 2 weeks in the project easier for them, and easier for
us?
>>>>>>
>>>>>> One idea:  Think of the new volunteer startup tasks in terms of
>>>>>> "stages" or "levels", a defined set of reading and other activities
>>>>>> that leads them to acquire basic skills in our community.
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>> Level 1 tasks:
>>>>>>
>>>>>> 1) Read the following web pages on the ASF, roles at Apache and the
>>>>>>
>>>>> Apache Way
>>>>>
>>>>>>
>>>>>> 2) Sign up for the following accounts that every volunteer should
>>>>>> have:  ooo-announce, ooo-dev, ooo-users,  MWiki, CWiki, BZ, Forums
>>>>>>
>>>>>> 3) Read this helpful document on hints for managing your inbox with
>>>>>> rules and folders
>>>>>>
>>>>>> 4) Read this code of conduct page on list etiquette
>>>>>>
>>>>>> 5) Send a note to ooo-dev list and introduce yourself
>>>>>>
>>>>>> 6) Edit this wiki page  containing project volunteers. Add your name
>>>>>> and indicate that you have completed Level 1.
>>>>>>
>>>>>>
>>>>>> Level 2 tasks:
>>>>>>
>>>>>> 1) Using the Apache CMS in anonymous mode
>>>>>>
>>>>>> 2) Readings on decision making at Apache
>>>>>>
>>>>>> 3) Readings on project life cycle and roles within the AOO project
>>>>>>
>>>>>> 4) Introduction to the various functional groups within the project:
>>>>>> development, qa, marketing, UX, documentation, support, localization,
>>>>>> etc.
>>>>>>
>>>>>> 5) Pick one or more functional groups that you want to help with.
>>>>>> Edit the volunteer wiki and list them.  Also indicate that you have
>>>>>> now completed Level 2.
>>>>>>
>>>>>> Get the idea?  After Level 2 this then could branch off into
>>>>>> area-specific lists of start up tasks:  how to download and build.
>>>>>> How to submit patches.  How to update a translation.  How to define
a
>>>>>> new test case.
>>>>>>
>>>>>> Is any one interested in helping with this?
>>>>>>
>>>>>>
>>>>>
>>>>> Quick update.  I have drafts of a few of the pages ready.
>>>>>
>>>>> 1) New Volunteer Orientation root page:
>>>>> http://incubator.apache.org/**openofficeorg/orientation/<http://incubator.apache.org/openofficeorg/orientation/>
>>>>>
>>>>> 2) Introduction to Contributing to Apache OpenOffice (Level 1):
>>>>> http://incubator.apache.org/**openofficeorg/orientation/**level-1.html<http://incubator.apache.org/openofficeorg/orientation/level-1.html>
>>>>>
>>>>> 3) Intermediate Social and Technical Tools (Level 2):
>>>>> http://incubator.apache.org/**openofficeorg/orientation/**level-2.html<http://incubator.apache.org/openofficeorg/orientation/level-2.html>
>>>>> (around half done).
>>>>>
>>>>> I could really use some help drafting the area-specific Level 3 and
>>>>> Level 4 pages, from subject matter experts.
>>>>>
>>>>>
>>>>>  -Rob
>>>>>>
>>>>>
> Rob, I think what you have is good enough to put out there *now*, even
> without the other modules completed.
>
> Yes, we have a lot or organizational aspects (still) to get through, both
> in terms of people AND information, but we need to start someplace.
>
> I would suggest linking this area either from "Get Involved" (with some
> appropriate subject and maybe remove the Mailing list link since this topic
> is covered in your material) or "Community FAQs" or both from:
> http://incubator.apache.org/**openofficeorg/<http://incubator.apache.org/openofficeorg/>
>
> Please JFDI! :}
>
>
>
>
>>>>>
>>>>
>>>>
> --
> ------------------------------**------------------------------**
> ------------
> MzK
>
> "Anyone who considers protocol unimportant has never
>  dealt with a cat."
>                                -- Robert Heinlein
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message