On Fri, Oct 19, 2012 at 5:47 PM, jan iversen <jancasacon...@gmail.com> wrote: > I think it is a good starting point, however I dont like the notation > "level 1", is looks like a graduation process, and I have to ask myself > where am I on that latter. >
I don't want suggest that everyone must go through these steps. An experienced open source volunteer probably would just skim this material. Someone who is a Committer on another Apache project would probably skip over it altogether. The name "Level 1" doesn't matter. We can call it "Stage 1", or even "Introduction". But there is an explicit ordering, and giving numbers is the natural way to express an ordering. But I am sensitive to having these stages give the feeling of accomplishment without becoming unwelcome status markers. > 1) Introduce yourself (by the way I think I have forgotten that). > why do it on the mailling list, when Wiki ask you for more or less the > exact same type of information. > This is more for the benefit of existing project volunteers already subscribed to ooo-dev. This gives them the opportunity to see who is getting involved. They might recognize some names. If so they can reach out to offer additional help and encouragement. > 2) I like that. > > 3) +1, but I will never understand why it is a mailing list and not a > forum, where it is so much easier to look at history > Mailing lists are the lowest common denominator technologies. You can access email from nearly any device, online or offline, using plain text. It is important to note that as a project we don't directly control mailing lists, websites, Bugzilla, etc., except at the level of the content and application admin functions. The sysadmin functions are done ASF-wide by a group of volunteers that we call the Apache Infrastructure team. Since they are maintaining services for over 100 projects, there are limits to how much customization each project can have. This is a consideration for maintenance as well as server resources and security. So there is a something like a "menu" of tools we have access to, and which are supported by the Infra team. But changing the menu is more difficult. > 4+5) yes, but that has not much to do specifically with AOO. > Right. But these are practical issues that have come up with past volunteers. For any such document we need to assume some initial skill/knowledge level. This means those who have these skills already will find some items unnecessary. This is hard to avoid. > 7) the project planning part seems a bit of a contradiction, look at > localization planning as an example. > Maybe calling it "Project Coordination" would be more accurate. CWiki is what we've been using to coordinate the various efforts of a major project-wide initiative, like a specific release. For example, we're using a page now to coordinate graduation-related infrastructure changes: https://cwiki.apache.org/confluence/display/OOOUSERS/Graduation+Infrastructure+Changes > Sorry for being frank, I do not want to be non-polite, but a lot of these > items just highlight my difficulties. > Nothing on this page is going to help with the current localization process. I'm hoping that, with your help, we resolve that in parallel. -Rob > All aside, I think we are making huge steps in the right direction and that > is what matters !!!! > > jan. > > > On 19 October 2012 22:07, Rob Weir <robw...@apache.org> wrote: > >> On Fri, Oct 19, 2012 at 12:17 PM, Rob Weir <robw...@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: >> > >> >> To make it more concrete, this is what "Level 1" might look like: >> >> http://incubator.apache.org/openofficeorg/orientation/level-1.html >> >> -Rob >> >> > 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? >> > >> > -Rob >>
