+1 Anything is better than nothing !!! and afterwards it can be improved. jan
On 24 October 2012 18:49, Kay Schenk <[email protected]> wrote: > > > 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/<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 >
