Hello Peter, All, because everyone (else) seems to agree on volunteer@ please note it's fine for me. Please do _not_ consider my vote for recruitment@ as a veto (in case you were in doubt :-).
Now to Peter's reply. On Wed, Jan 13, 2021 at 10:29:28PM +0100, Peter Kovacs wrote: > Hi Arrigo > > I like the Idea to post Tasks onto Recruitment. I will try this. > > However, I try tried to give people tasks that were signing on, and it never > worked out. > > Maybe I am a bad recruiter. I leave that to other peoples decision. You can > read my posts on recruitment and what I tried. > > I have mostly wrote stuff like this here: > > https://lists.apache.org/thread.html/0a16093227325324ea57fb07cf8e08a7902c0f365792c14065de88ac%40%3Crecruitment.openoffice.apache.org%3E > > As an answer when someone posted interest. > > I have asked people to talk to me, and figure what they can do and tried to > give them a choice of Issues. Even look for more if they are not interested. > > But in the end, I could recruit no one. So I would like to change tactics. > And one thought I have is that a lot of people think that ASF is a Company, > or they do not differ between ASF and a Company. OpenOffice is also only a > product to them, and not a project. Thank you for sharing this information. First of all, I am happy to see that you tried. I cannot say wether you are a good or a bad recruiter, because I have no experience of recruiting free software contributors. But I really appreciate your effort. > We have mostly Issues. Crashes, out dated stuff. Boring maintenance. There > are only 2 topics for features. That is OOXML and ODF 1.3. Well... maintenance has kept me busy so far, and I personally enjoy fixing bugs. I think it's a good starting point for newcomers to get accustomed to the huge code base, one piece at a time. I am still learning, of course. On the other hand, before someone could help with the two features you pointed out, they should have: A- good knowledge of the AOO code base; B- good knowledge of the OOXML and/or ODF file formats; C- possibly experience with other programs and/or file formats, in order to be able to use patterns, best practices etc. from the field. I personally find utopistic to find _one_ of the three condition above in a newcomer, let alone all of them together ;-) As a ``non-rockstar'' C++ programmer, I could instead be helpful with blatant bugs crashing AOO. Any C programmer understands a null-pointer dereference! I just had to read the "debugging" wiki page carefully, to make my (small) experience with gdb useful. What we need, maybe, is an expert developer who is able to break the bigger problems into smaller ones, that could be assigned to newcomers, with lower barriers to entry. > I try to get a concept for base together. I will make my next step on > FOSDEM, but as you see I take my time. And it will be a long time until > I suggest actual work. And Base is the simplest of all the applications we > have, because it is the "least used". > > I hope you understand now more where I come from. I understand and, again, for what my humble opinion is worth, I appreciate your efforts. > I am a bit astonished that no one screams on the hierarchy suggestions. I > think we do not need them and we can continue with our rather anarchic > approach with similar success. > > But I think this is a completely different discussion. Maybe no one read through my whole message ;-) In fact, we could discuss about ``organization'' rather than hierarchy; I could have used a better wording. I do not want to ``give powers'' to anyone, but rather individuate a ``leader'' as someone who ``leads'' in terms of ``goes ahead and shows the way''. That is what experienced developers and contributors here IMHO would be _very_ fit for. And without this kind of leading, I believe, bigger improvements will be very, very difficult. I hope I could explain myself clearly, and most of all, I hope that it is clear that all I am writing is aimed at achieving higher goals as a project. And that the purpose of my messages on this thread is to understand: can we recruit and organize small groups of people (inside the existing doc, dev, QA groups) or is it against the policies here? If we agree on this, then we can pass to a second level of this discussion: what ``big'' projects are worth organizing our efforts on. This should happen on a new thread, but just because we are here... you mentioned ODF and OOXML, but we could also add: - squash bugs blocking the next 4.2.0-Dev, - update obsolete modules (Boost, Python, NSS etc) - support newer Java releases, - your upcoming proposal for Base, - ... whatever :-) I could start myself trying to ``recruit'' volunteers on my pet peeves: - documenting the source code, - enhancing error reporting and logging, but I would rather work for some time on a project driven by someone with more experience than me, before starting up my own. Thank you and best regards. > On 13.01.21 11:24, Arrigo Marchiori wrote: > > Hello Peter, > > > > thank you for having raised this issue. I have some ``deeper'' > > questions about the philosophy of the project itself, and about its > > organization. Please see below. > > > > On Wed, Jan 13, 2021 at 09:25:14AM +0100, Peter Kovacs wrote: > > > > > Hello all, > > > > > > I wonder if we can rename the recruitment list to something else. My > > > theory > > > is that a lot of people do not understand OpenSource in general, and > > > recruitment is commonly strongly linked with Job offers. So have the > > > theory > > > people write us with the hope on a job. > > > > > > Maybe a better name would support a better understanding, on how we work > > > or > > > what to expect. > > > > > > Maybe something like enlistasvolunt...@openoffice.apache.org? > > > > > > Or simply volunt...@openoffice.apache.org or enl...@openoffice.apache.org > > My quick reply to your answer: IMHO (as a non-native English speaker) > > the term "recruitment" is already good enough to describe "enlisting > > as volunteering". It's very clear that everyone here is a > > volunteer. Moreover, you don't have to be a recruiter to write to > > recruitment@, as you do not have to be a developer to write to dev@ > > (as it is happening for applications to test release candidate 4.1.9) > > > > --- Longer pilosophycal reply starts here --- > > > > This part is about "how we work and what to expect", as you wrote. > > > > From my very short and limited experience, I have seen quite some > > enlistings: people who wrote "hello, here I am, I am good at this and > > that". > > > > But I have hardly seen anyone working as a _recruiter_, in terms of: > > "we have to do X and Y. Who is available to help?" > > > > So my question is: can we use that list for actual recruitment, in > > terms of gathering people around a sub-proect? Such as "let's refactor > > module X", or "let's document module Y", or whatever we think: > > > > - would be a Good Thing for the project and > > - needs a coordinated effort because it's too much for a single > > volunteer. > > > > Such coordinated efforts would need a... coordinator, with the ability > > to tell volunteers "let's do X, let's not do Y". In other words, a > > simple hierarchy. > > > > I am asking this because I am not sure, from what I understood of "The > > Apache Way", how much hierarchies or sub-groups are > > tolerated. Moreover, the only "structured" process I have encountered > > in my short experience is the preparation of a release, that involves > > the full developers' community. > > > > But from what I have seen so far, Open Office is a _huge_ project, > > that carries the work of _many_ hands. It is IMHO unrealistic to > > expect a real evolution of this software if we do not start working in > > task-oriented groups. > > > > If the answer is yes, that the Apache Way and the project's philosophy > > have nothing against simple hierarchical working groups, then > > "recruitment" is (still IMHO) a _very_ good name for the list, and we > > should take full advantage of such name: _let's use it_ for hiring! > > :-) > > > > Trying to better explain my point, here is a fictional example > > sub-project: translate all source code inline documentation into HTML > > format. All names are fictional. > > > > 1- J. Doe sends a [PROPOSAL]; we discuss it on the dev@ list and > > agree that it is a Good Thing. > > > > 2- J. Doe and F. Bar take the responsibility of coordinating it, > > > > 3- J. Doe sends a "recruitment" message to _both_ dev@ and > > recruitment@ telling "let's do this; contributors welcome; we start > > on Octember 36th, reply to dev@ if interested". He may also dig in > > the recruitment@ archives and directly contact people who introduced > > themselves in the past, may be fit for the job and may not be > > subscribed to the list. > > > > 4- J. Doe, F. Bar and the other volunteers carry out the task, using > > the dev@ list when necessary. If recruited volunteer B. Etor says "I > > would like to do it bi-lingual: English and Klingon" then F. Bar has > > the authority to say "no thanks, please let us stick to English". > > > > I hope I could explain myself clearly. Please do not see this as > > hijacking your discussion thread, as I am just trying to fully > > understand the term "recruitment" and therefore the role of the > > corresponding mailing list. > > > > If this topic has already been discussed in the past (and honestly, I > > would be suprised if it had not :-) please send me the pointers. > > > > Best regards, > -- > This is the Way! http://www.apache.org/theapacheway/index.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- Arrigo http://rigo.altervista.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
