On 10/24/2012 09:40 AM, Rob Weir wrote:
On Wed, Oct 24, 2012 at 12:30 PM, jan iversen <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:

On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir <[email protected]> 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/

2) Introduction to Contributing to Apache OpenOffice (Level 1):
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
(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/

Please JFDI! :}






--
------------------------------------------------------------------------
MzK

"Anyone who considers protocol unimportant has never
 dealt with a cat."
                               -- Robert Heinlein

Reply via email to