We can hardly say that Apache LABS is a top level project. Though shrouded with some aspects of a TLP cloak it can't be regarded as anything else than an ASF experiment to facilitate the privileged contributors of any given true project. At best one could regard it as a service by ComDev/Infra to the projects.
And I would say that given the multitude of external facilities available outside of the ASF (Sourceforge, Github, etc) that it has reached the end of its lifespan regarding its goal, being enabling committers to collaborate in experimenting with solution approaches that don't fit within the projects they are contributing to. Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Mon, Jul 6, 2015 at 3:10 PM, jan i <j...@apache.org> wrote: > On Monday, July 6, 2015, sebb <seb...@gmail.com> wrote: > > > On 6 July 2015 at 10:24, jan i <j...@apache.org <javascript:;>> wrote: > > > On 6 July 2015 at 11:10, Pierre Smits <pierre.sm...@gmail.com > > <javascript:;>> wrote: > > > > > >> Thank you, Branko. I feel (somewhat) sorry for you, when I read your > > >> statement of being disgusted by the viewpoint of others on the > matter. I > > >> hope you recover from it soon. > > >> > > > > > > Having been (and still be) in a project that have strong bylaws, > limiting > > > voting etc, > > > I know what a PITA project bylaws can be. > > > > > > We fought for about 6 month to get the bylaws changed, to something > there > > > was > > > total consensus about. The problem was that the bylaws could only be > > changed > > > with 2/3 +1 of all PMC, which is quite hard to reach when 1/2 of the > PMC > > no > > > longer > > > are active. > > > > As I recall, the main problem was that the local project bylaws had > > been badly drafted, and were not clear, so needed to be changed. > > > the bylaws was very clear and understandable but drafted in a time where > LABS was a active project. > > > > > > > > Bylaws can in some special cases help a project, but really should not > be > > > necesary. If > > > our bylaws and policies are unprecise we should do something centrally > > and > > > not remedy > > > this problem in 200 projects. > > > > Indeed. Had the local project bylaws not existed, I suspect there > > would have been no problem in the case to which Jan refers. > > > Correct actually LABS is a good example of a project where the bylaws are > not needed. > > rgds > jan i > > > > > > rgds > > > jan I. > > > > > > > > >> > > >> Best regards, > > >> > > >> > > >> Pierre Smits > > >> > > >> *ORRTIZ.COM <http://www.orrtiz.com>* > > >> Services & Solutions for Cloud- > > >> Based Manufacturing, Professional > > >> Services and Retail & Trade > > >> http://www.orrtiz.com > > >> > > >> On Mon, Jul 6, 2015 at 10:51 AM, Branko Čibej <br...@apache.org > > <javascript:;>> wrote: > > >> > > >> > On 04.07.2015 18:34, Pierre Smits wrote: > > >> > > Having done a cursory review of the incubator reports to the board > > for > > >> > > this year (January till May/June 2015), I found that only the > SAMOA > > >> > > podling reported working on a project set of bylaws, which without > > >> > > knowing details could encompass and/or incorporate the code of > > conduct. > > >> > > > >> > I find myself disgusted by this widespread assumption that each > > project > > >> > needs its own bylaws. WTF for? Are not ASF policies and practices > > enough > > >> > for everyone? What sort of bylaws could you possibly invent that are > > >> > both a useful extension of these policies and practices /and/ are > not > > >> > applicable to other projects? > > >> > > > >> > Per-project bylaws are just a tool for fragmenting the ASF > community, > > in > > >> > other words, they're a bad idea; paper-shuffling at its most > useless. > > >> > > > >> > -- Brane > > >> > > > >> > > > > > -- > Sent from My iPad, sorry for any misspellings. >
