On Thu, 6 Aug 2009, Marcus Moeller wrote: > I recently started thinking about how to make a project like CentOS > more transparent and open (especially for new contributors). I have no idea what meaning to 'transparent' you have in mind -- all mailing lists of public character are open; the forums are open, the IRC is open, the documentation is open, the source changes are published openly. There has to be someone attending to infrastructure matters, but a newcomer is not going to be offered access to that. As noted here and many other places before, CentOS runs as a meritocracy. Some people are perhaps offended that the less public CentOS infrastructure levels do not invite them in -- I cannot help their wounded feelings. Indeed, in part it may be that some talented people drift away or withdraw for such a reason. While I regret the loss of their enthusiasm, there is an art to 'keeping the lights on' at a major distribution > The http://wiki.centos.org/Team page (which Dag created > about a year ago) lists about 20 (more or less active) > members, divided into core and community contributors. I > personally do not like that kind of distinction. You entitled to hold your likes and dislikes of course, but this will not necessarily something the project is going to address. I have been critical on the -docs ML as to re-inventing the documentation wheel in the wiki, and will continue to do so, for the reasons I have stated there. The wiki is un-vetted content, and parts of it are stale or wrong, in my opinion. You've found a stale one to the extent it purports to represent the organizational structure. Perhaps I'll go clean it up -- but more likely I'll attend to 'hotter' tasks I am part of the CentOS team, but speaking as to just MY opinion, I am just not interested in 'competing' with El Repo, or RPMforge, or EPEL as I see the core mission of CentOS to be to recreate, warts and all, a trademark elided rebuild of the upstream's freely released sources in as close as possible binary identical form, with changes related to our approach on updater attended to. I know others have other additional goals to that, and CentOS offers a big tent -- but at the end of the day, tested and vetted install images and timely updates makes CentOS successful. We have under 15k unique mailing list subscribers, all told -- under 500 peak participants in IRC; bugs and the forums have active participants in the scores, and low hundreds respectively. Overwhelmingly CentOS is about the binaries I see at that wiki page a distinction gradient between core and community in building out the 'teams' on wiki page you refer to -- I have no idea as to the thinking behind such. It did not and does not match the functional divisions or task groups in the project -- then or now -- In checking the edit log, the people doing edits largely did not then have visibility into certain layers. I had not audited it for accuracy; a quick scan shows some glaring errors. But in another way, there is a historical reality of doers and watchers and talkers, in this project, in many FOSS projects, and in politics and life in general. > As we are a community of ppl with high technical skills probably only > persons with a valuable number of contributions and knowledge will be > elected to the board. A board member could of course be responsible > for core dev tasks, too. > > The board itself could consist of a mix of technical, marketing, or > legal orientated ppl. It could -- but only if it were your intent to have such a board to kill the project off. Frankly, the next decisions in project organizational matters are not ones that you and the community can make at present. The core group are coming through a delicate time, and is in process on some matters of reorganization. But, this conversation has been underway for a long time, and so will not be conducted in the first instance here and in public. This is not because of a desire one way or the other to exclude, but because the first instance started years and years ago. I am not trying to be mean here, but that is the truth. Marcus -- you've seen the 'galley' on my interview in the upcoming Pulse -- we were leading into this while 'centos' was still a nascent sub-project at cAos. It is also a truth I have observed that because there are doers and talkers, that after a while the doers tire of talk, withdraw from the talkers, and build a future. "Running code talks" so to speak. 'Thread capture' on mailing lists is a well known tactic, but just because 20 people can express a similar view on a list, it does not mean that it is right, or can be implemented, or that anything has been accomplished. > To make this happen, the new maintainer process has to be clarified > first. I am thinking about a (frequently maintained) list of open > tasks e.g. maintained within trac, from which a new (and even > existing) maintainer could choose one. Of course suggestions for task > that are not listed there could be published on the ML. And using 'maintainers' as a starting point makes it clear that the reason why CentOS has been successful, as a fairly literal rebuild, is not clear to you -- We have very little to 'maintain' in the core project -- solving build issues, yes -- perhaps tweaks around the edges in the centos-plus kernel and so forth. Those '-plus' tweaks happen with the bug tracker, and IRC discussions in -devel. Most of our 'maintenance' comes with SRPM releases upstream, and the builder's solution and verifications Open tasks in Yet Another Tracker sounds great until one realizes that 'trac' has had security issues. Question: Who gets to pay that maintenance load? Answer: The infrastructure group. That responsibility cannot be delegated, and in this instance 'trust matters'. We have finite resources. > The 'Team' page should list major tasks one is working on or > responsible for. and I should have a pony. and the day should have 40 hours. I'd like August off work, but I live in the US But the hard fact is that CentOS has been, is, and will remain a reliable approach for millions of systems, not with an 'open anything goes' management, but with a conservative and careful one, based on observed and continued technical merit by dedicated insiders. It is fantasy to think that the effort expended by the central project members would continue if 'guided' or 'controlled' by the hands of others with less technical skills > If one needs help (e.g. I am in need of help for the > website update), he/she could add a note to this task list (and maybe > even announce on the ML) with contact details (wiki homepage). I see Ralph's quick answer as to some matters within the wiki space, and will not continue The wiki rots -- I've said it over and over, and would radically scale it back. It is not sensible for you to have surfaced the remainder that I have trimmed off here when you are on the -docs mailing list. Take it there. Again -- this is just MY personal view as one of several in the core management of CentOS. I know there are differing views, but this is how I see it -- Russ herrold