On Mon, Sep 12, 2011 at 6:50 AM, Ian Lynch <[email protected]> wrote: > On 12 September 2011 10:55, Ross Gardler <[email protected]> wrote: > >> The ASF does not like umbrella projects. We used to have them, but >> they lead to hierarchical structures that make oversight difficult and >> confuse the decision making process. >> >> OOo is such a large project it will almost certainly become an >> umbrella project, of sorts. We are already seeing this with the >> proposal of a Japanese language dev list. >> >> We need to manage this carefully. A Japanes language list to ensure >> non-English speaking people are able to participate in the project is >> fine. A Japanese language list for creating a different version of OOo >> for the Japanese market is not fine. >> >> If the IPMC (and later the Board) start seeing decision making power >> being delegated to sub-communities they will ask the PPMC (and later >> the PMC) to break-up the umbrella project. This will require the >> sub-projects to be spun out into their own project. We've done this >> very successfully on a number of occasions, it is not something to >> worry about. I merely want to flag this so that we can manage the >> creation of things like the Japanese language list correctly so as to >> minimise the work needed in the near future. >> >> I'm not seeing a problem at this point. I'm merely letting the >> community know that this could become an issue if we don't keep a >> careful eye on it. For me the trigger point will be delegation of >> decision making responsibilities. >> > > Let me set up an "Aunt Sally" (target for criticism) as to how this might > work. The NL list/forum/comms technology allows discussion and quicker > decision making in the native language. If the outcomes of those decisions > affect code to be released or the associated IP, they then go to the Apache > list in English as a proposal or if it's a code patch a Committer commits it > in the usual way. In this way there is never any problem with a separate > project developing, it is not really different from me having an off-list > chat with some like-minded people about the project and then deciding to put > a proposal forward as a result. The key issues I see as needing an answer > from a practical point of view are: >
Surely the PPMC uses ooo-dev for decision making related to more than just things that "affect code to be released or the associated IP"? We use ooo-dev for all project decision making. It might be useful to think of the decisions that an individual contributor or committer can make on their own, without making a proposal, seeking lazy consensus or having a vote: 1) I am going to work on X 2) I am going to investigate X 3) I am going to fix bug X and commit the fix 4) I am going to update the website 5) Other similar JFDI things And the things that we have had formal proposals on ooo-dev in the past, or where I would anticipate using it in the future: 1) Migration proposals 2) Discussion of addition of new features 3) Review of new blog posts 4) Creation of new blogs posts 5) Discussion/voting on a release I'd expect that anything that a committer can do on their own, without making a proposal, could also be done by one or more committers talking on another list. But anything that a committer would ordinarily seek lazy consensus on ooo-dev should continue to be proposed and reviewed that way, even if it had a preliminary discussion on another list. The thing that makes this a single Apache project is that we have a single PPMC that provides oversight. Personally, I think it is fine to have several lists of discussion on specialized topics. (I also think it is fine to have a single list for this, so long as we use [subject] tags consistently.) But however we do it, it is important that there is a single place for the PPMC to find proposals, and that place is ooo-dev. This doesn't mean that everything must be a proposal. There is still scope for JFDI. It just means that where a proposal is needed, it must be made on ooo-dev. > If there is to be a NL build of the AOO product to be > released, presumably that build will take place at Apache? Or could it take > place elsewhere but only be formally released by Apache? It seems to me that > since mirrors for distribution are normally widespread anyway, the issue is > where the build and release takes place. > There are a number of requirements of an "official" Apache release. You can see the podling release guidelines here: http://incubator.apache.org/guides/releasemanagement.html > Where will an extra-Apache community infrastructure reside? If the Oracle > servers are switched off and Apache doesn't host it, some other host has to > be found. Is that simply a matter for the NL communities to be resolved > individually? What happens if they can't resource it and it looks like all > their resources will be lost when Oracle decides to switch off the servers? > I see no reason why we could not create users-xx.i.a.o mailing lists for user communities in other languages, provided we had sufficient moderator volunteers. Similarly, we have a community wiki in confluence, as well as the MWiki that could be used for NL-specific community-maintained pages. I think it is very easy to do the above for any NL group. Of course, some of the NL projects went beyond that. More things may be possible. But we probably want to have that discussion on a case-by-case, lead by a proponent from the specific project. A sign that an NL project has sufficient vitality to survive is that it has sufficient vitality to put together a proposal for us to review. On the other hand, has anyone ever reached out to the 160 language projects to let them know that migration of their projects is not automatic? > Ross >> >> >> -- >> Ross Gardler (@rgardler) >> Programme Leader (Open Development) >> OpenDirective http://opendirective.com > > -- > Ian > > Ofqual Accredited IT Qualifications (The Schools ITQ) > > www.theINGOTs.org +44 (0)1827 305940 > > The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, > Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and > Wales. >
