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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
