Dear Community, I recently started thinking about how to make a project like CentOS more transparent and open (especially for new contributors). 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. Of course there should be something like a 'board' and clear responsibilities (release management and such), but at least the board should be elected by all active members. 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. 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. The 'Team' page should list major tasks one is working on or responsible for. 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). Other areas of taking part should and are already covered on: http://wiki.centos.org/Contribute But some aspects are still unclear: THE WIKI: For me a wiki is a collaboration platform which should be accessible to every contributor in the same manner (except the front and user pages). That means there should be a join process (where you have to agree to the cc license) which then leads to EditGroup membership. I do not see a good reason why new articles should first be published on the ML. A user should be able to add a new article and then announce it on the ML (if necessary). Same on the personal pages. Of course it makes sense that new users introduce theirself on the ML but they should already have access to their own personal page, before. A comment function could be a good feature but in a comparatively small community like ours, most of everything can be discussed via ML or could be handled through page changelog. I personally see no reason to honor authorship of created pages besides the wiki page history. THE BUGTRACKER: The CentOS bugtracker contains a lot of upstream bugs that cannot be fixed here. We have to make sure that these are tracked upstream and fixed there. THE CONTRIB REPO: This repository has been re-invited in CentOS 5.3 but it's still unclear what it's meant to be for. Could it contain non-free packages. Should'nt oss packages better be pushed to EPEL/RPMFusion or even RPMForge? Where should spec files go? Is there an SVN with write access and an automated build process, already? Barriers on this site should be lowered when it's clear what the repo is meant for. QA: Some of you might know that CentOS has got an QA process before releases. This is an closed process and invite only. There where some reasons for it (e.g. some ppl only took part in the beta program to get early access to upcoming releases) but an invite only QA could not be the solution. This process should be open to all members. BARRIERS: Overall, the barriers for new contributors are much too high. This can also be fixed with something like a mentorship program where longtime developers take care about new maintainers. Best Regards Marcus Moeller
Just to answer two of those questions: Marcus Moeller wrote:> THE WIKI: > > For me a wiki is a collaboration platform which should be accessible > to every contributor in the same manner (except the front and user > pages). That means there should be a join process (where you have to > agree to the cc license) which then leads to EditGroup membership.Yes. That hasn't been furthered by me because of what is in the open by now. I wanted to have some things cleared first - this has now happened.> A comment function could be a good feature but in a comparatively > small community like ours, most of everything can be discussed via ML > or could be handled through page changelog.There is no real functional comment function for moin, afaics.> THE BUGTRACKER: > > The CentOS bugtracker contains a lot of upstream bugs that cannot be > fixed here. We have to make sure that these are tracked upstream and > fixed there.Everybody is invited to help us to do that. Looks like there are only about 4 to 5 people who regularly look at bugs and take care about them without being pointed to specific bugs by others. This is something which has *no* barrier at all. Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20090806/bae381c8/attachment-0003.sig>
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
Marcus Moeller wrote on Thu, 6 Aug 2009 15:52:01 +0200:> Dear Community,I think the community would benefit from opening a new mailing list for these issues. There's already a promo list, but a discussion like this doesn't really fit on it. I also think it doesn't fit here. So, I think everyone interested about CentOS management should be able to do so on a mailing list "centos-community" or "centos-management" or so. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
On Sun, 9 Aug 2009 03:23:57 +0100 Marko Vojinovic <vvmarko at gmail.com> wrote:> Unfortunately, governments are typically not made of experts, but of > opportunists. Name one president of <insert your favorite political > entity here> that has been elected because he has a PhD in political > sciences/history/law/whatever, or because he had enough hands-on > experience in governing the state (maybe without a formal degree).Woodrow Wilson. Ph.D. in Political Science (John Hopkins), President of Princeton University, Governor of the State New Jersey, President of the United States of America.> Even if one such exists, I doubt he would listen to whatever > random non-initiated group of people are "suggesting".Then you would be wrong. Once his mind was made up then Wilson became quite closed to further suggestion on a subject. Up to that point he sought as wide and varied a range of opinion as he could obtain. Your pride in what you know is blinding you to the value of knowledge of others in areas where you know little and presume much. I have had much experience with volunteer organisations. I now stay well clear of any involvement with them. This recent string of interrogations by concerned people, whether ignorant or not, and the aggrieved tone of the responses of some of the inner circle demonstrate the type of emotional blackmail which I frequently encounter and find so distressful in these bodies. I have no doubt that everyone involved with CentOS is pursuing some goal that they believe serves the greater good. However, difficulties ofttimes arise when one encounters another who either does not share ones belief or, as is more often the case, understands the nature of the shared goal, or the means by which it is attained, in a fashion fundamentally at odds with ones own. These uncomfortable collisions with political reality often occur at junctures such as CentOS recently experienced. Most of the people here were no doubt quite content to allow the sages of the project whatever leeway that the sages desired. In return we got a free (as in beer) copy of a very reputable Linux distribution. Had the recent inner conflict not become public then this happy arrangement might have persisted indefinitely. I still consider this arrangement a very good bargain having neither the talent nor the desire to become a sage myself. However, when the mortal nature of the sages is revealed together with the possibility of a project collapse as very real consideration, regardless how unlikely, then those dependent upon the stability of the project become fearful. Fearful people seek reassurance that their fears are baseless. A bald statement by the sages that the fear is baseless is in itself insufficient. Doubtless the fearful have told themselves that many times already. Having inoculated doubt it is now incumbent upon those who sowed it to address specific concerns raised by those who fear. Telling people who voice concerns to get lost and find another distribution, even if their concerns are presented in the form of ill-considered suggestions, smacks of arrogance to me, however it appears to others. Further, it does absolutely nothing to address the fears that prompted the suggestion. The baleful effects of these kind of replies upon those who read but choose not to participate may only be imagined, but be assured they are neither positive nor insignificant. The fact that one is a volunteer leader does not lessen the requirement that to receive the trust and support of others one must meet satisfactorily the expectations of those who follow. I am not clamoring for any immediate changes. I do not propose a program that I wish anyone else to follow. I do appreciate very much the efforts of all who contribute to the success of the CentOS projects. I further acknowledge that those who presently form the core support team are probably best equipped to evaluate the bona fides of prospective core members. Nonetheless, it is very evident from the heated exchanges on this mailing list that there exists a substantial divergence on which path to take from here. It seems to me insupportable that the past practices of a small coterie of initiates deciding on everything without community input will suffice for the future. If that does become the choice taken then I foresee the community splitting in the future in consequence. Finally, please drop the word "meritocracy" in future communications. It implies a natural worthiness of those to whom it is applied which is simply not appropriate to these discussions. The proper word in this circumstance is "oligarchy." -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Ian Murray wrote on Tue, 11 Aug 2009 05:51:05 +0000 (GMT):> I hit reply and changed the subject.Please stop doing that. That's what I do on my local> LUG list and nobody complained so, I don't know if I have committed > some list faux pas, so apologies if I have done.It's wrong for every mail conversation.> > Perhaps you can set me straight on where I am going wrong?Send a new message. If you hit "reply" then the threading information (in -reply-to und references headers) gets inserted as well and thus the message gets threaded to that thread. Opposite to what some people who are new on the net believe the threading is *not* done by the subject but by the threading headers. The subject gets used only in case the threading headers are absent. Kai -- Kai Sch?tzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Hi, Late to the party, oops! Everything in this email is my personal opinion, and I speak for myself not the project here. Just as Russ and Johnny dont speak for the project either in their emails, they speak for themselves. On 08/06/2009 02:52 PM, Marcus Moeller wrote: > I recently started thinking about how to make a project like CentOS > more transparent and open (especially for new contributors). There are a lot of good ideas in your mail, Marcus - however some that are mis-aimed, not your fault, and maybe not taking the entire CentOS context in mind. But everyone of them put forward with good intent. The conversation that followed from there is also very interesting, some of it made me sad though. CentOS has been quite an experience over the last few years and I think a few things need to be put into context. Kai, if you dont want these emails, setup a filter for yourself or unsubscribe from the list for the duration of the conversation. Given the traction this has and the context of the conversation, I feel its important that it gets somewhere. Anyway to kick things off, here is a bit of history to start with : CentOS started way back when..... We had no management, there was little or no direction and people didn't care much about things. A few of us ( mostly Johnny and me, to be honest ) took up the task of fixing stuff and making things happen. And because we used it and because we were able to[1], it was the norm spending the 36 hrs /week on the day job followed by the 30hrs/week on the CentOS 'job'. Its pretty much stayed like that for years, when Ralph and Tru got involved with the infrastructure side of things and Ralph took up the additional task for 'being chief executioner' on the wiki. Tim has been an even more recent addition to the 'team'. And this is even before we start talking about the distribution. Most of us do other things as well, like help and work on building a distro[2], Some of the people on this list might have heard of it. One of the important things to keep in mind is that CentOS hasent been an accident. We had decided very early in the lifecycle ( Jan 2005, I still have the logs from the conversation ) that we would either do things the right way, or not do them at all. I guess that paid off long term, even at the cost of personal loss ( I've lost count of how many times people have called me all sorts of things ). So, effectively late last year, we decided that things were getting a bit mad and something had to be done. And we setup the infrastructure group to keep things moving along while we looked at options and also tacked other issues, which needed attention. Much of whats been going on recently in terms of the 'project issues' with the media is negative spin to what I'd say is a good thing for the project. We are at a stage where we can restart, with much hindsight and a clearer idea of what needs doing and how it needs doing. We also realise that while we made mistakes along the way (eg. the QA Team ), somethings we did get right. So let me lay out what I'd consider an ideal situation that we can build on from here. Remember, that this is my personal take on things. Much needs to happen before some of these are even considered. The first thing that we need to do, all of us, is step back a bit and see exactly what CentOS is. I think about 80%(guess) of the contributors to the thread already, dont seem to know or prefer to ignore it as they foster a deam of something wildly different. Anyway, whichever way you spin it - CentOS is about the people. The people here. Its not about the distribution. Its not about any 'team', its not about the infrastructure or the means for the infrastructure. Its a group of people, who all use/abuse a common code base. Therein lies my take on what is the 'C' in community. I'd be happy to clarify and explain ( although Smooge and Mike already do a great job of that ), if anyone still cant 'get it'. CentOS, in its early days was about the optional setup to EL, in the last few years its become about the people. Even if you dont agree with me and try to spin it otherwise. At the core of this group-of-people is a codebase that we dont change, we dont edit, we dont 'develop' on[2]. Look at the wiki, look at the forums, this list, look at the companies who base their products on CentOS - and you will see this community. People who 'get it', and are offering to help others 'get it'. So, I think lets start by first defining what it is that the 'CentOS Project' stands for. Johnny already pointed people at the website and whats on there. I think now would be a great time to redefine that into a real 'charter' or a 'mandate'. Having said this, I also realise one thing that we got really wrong was calling people 'CentOS Developers' and others 'the Non Developers'. A more apt name for these people would be 'administrators' ( or even something else ). These are the people who keep the 'stuff' working, they 'facilitate' the community. They are not the community or even try to be them. We got it wrong. Lets fix it now. Fix what ? Well, for one - a contributing community needs to have something to contribute to. Also, as I said earlier, the community is the people, and they are people based around a shared interest in a common codebase. A codebase that is essentially open source. So the ability to expand and promote that codebase should be something we can 'facilitate'. A process would need to be defined, and I am sure there are enough people around who can help with that process definition. But once its in place, I see no reason why it cant be done. Exactly who gets to make the decisions that would then in turn influence the whole userbase ? One way would be to have everything churn through a mailing list and have everyone contribute a voice. Something that works well in some cases ( package policy definition would be a good example !), and in other cases thats a really bad choice ( are we going to use machineX for DNS or a torrent seed ). Most users dont care as long as a 'reasonable expected level of competence' goes into making these decisions. And these are the sort of decisions that need to be made within a specific user group. Could they be done in public ? I am sure some can. while there are plenty which cant. My point here is that while there are some things that can really go into a circular route and stay open ended, others cant. And this is where I feel a 'admin/core/infra' team fits in. The list of people who work within this team should also be mentioned, but all contact and work / requirement work done through 'role' accounts actively discouraging personal contacts. Similarly, I feel we need to have a 'control group'. Someone who can look at issues like donations, management of funds, management of any centos branding and also be the focal point for the promo efforts[3][4]. A group that is built initially from the existing core group and initially atleast, based around an invite only process. However, this group should be put into place with a reasonable transparency process in place. Exact extents on this and the mechanics of how this would work is something that is still pretty much in the air. Anyway, so where does this leave the 'developer person'. As I see it, anyone 'doing stuff' on projects.centos.org should be able to call themselves a CentOS contributor. Anyone doing anything else can call themselves whatever else they want. So where does this leave the 'build people' ? I'm going to propose that the build-group/ key-holder group stays small, invite only. However, let people from the community have a mechanism to help with the process. Remember, the action is not going to be in signing packages, its in making sure that things are doing what they need to do. What I am also going to propose is that the infrastructure for this stays where it is. We have major wins in keeping the buildsystem offline, not only the security part - but also the wins we get in manageability are worth a lot. Besides, mock hosted builds local to where the contributors want to be are trivial these days. Also, with the keys - we dont even need all the people doing builds to hold keys. There are, as most people know, issues within the way things are pushed out right now. Packages that should take a few hours or even a day sometimes, take a much longer time to get there. And this is a very real problem and something that needs addressing right away.[5] I just want to finish this brain dump off by saying that there is no reason to panic, we are changing things and we will change things in the long term best interest of the project. Exactly what we change and how and why and when would be things that I will attempt to bring into a place where there is plenty of option for user feedback. And feedback, before things change up. End of the day, if we cant convince the users about what we are doing as being in their best interests, perhaps were doing things wrongly - and we should take that on board. - KB [1]: Not easily, but we made the efforts. Just as the other guys do now as well. [2]: I have a few ideas on why only idiots merge 'development' and 'distro' into one set. Will collect and post those thoughts elsewhere. [3]: This needs to be extremely transparent, and the idea of a foundation does sounds very enticing. And is being actively pursued at this time. [4]: the 'promo' group again is something which we got the naming for quite wrong. its more of a 'conference' group. [5]: there are other things that need attention as well, but changing too much at one go, specially with the build setups is going to break way too much. so one problem at a time. If you are interested in helping, track centos-devel list for a few weeks -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq
Ian Murray a ?crit :> Niki, > > I am perfectly comfortable with my email client and I prefer top posting > because I don't like wading through constantly re-quoted stuff I already > read. I will on occasion interleave and bottom post if it serves my > purpose, though. If you don't like it, don't read my posts. >Some folks just humbly take the advice and adapt to a community's rules. Others remain draped in their glory and don't mind telling everybody they prefer doing so. This reminder probably doesn't "serve your purpose", as you say. Well, just follow your own advice. Don't read it. :o)
Ian Murray a ?crit :> > Nobody said I was breaking rules, only that I annoyed them. >Then let me apologize for having bothered you with outdated concepts like respect, politeness or consideration. Believe it or not, I just took a peek in my Oxford Dictionary: "egoism, n (usu derog) state of mind in which one is not concerned by the immediate wishes or needs of Ian Murray". Cheers from the sunny South of France, Niki Kovacs