On 3/20/06, Daniel Drake <[EMAIL PROTECTED]> wrote: > "more open"? I can't think of a decent way to phrase the subject line > which might make it sound it was coming from a native English > speaker..ahem..anyway: > > I read a complimentary comment from a Gentoo user recently (can't > remember exactly where, so this is from memory). It was something along > the lines of "Gentoo is great and will continue to be great for the > foreseeable future. You have built the required structure to keep up > with the rate of change in your environment (i.e. the increasingly rapid > rate of development of open-source sofware)." > (if anyone can point me to where I read that, I'd appreciated it). > > I think there's a lot of truth in that, especially the way that he/she > highlights the fact that simply keeping up with what goes on around us > is key to our "survival". > > I won't go as far to say that I *don't* think we can keep up with our > current "system", but I think there is plenty of room for improvement. > > One of the bigger problems is that we have a huge user community who are > keen on contributing, but we have such a high barrier for entry to the > developer community. Quite rightly so - we're dealing with a live tree, > so we can't give out commit access on the street. > > At the same time, I feel that we're missing out. Comparing Gentoo with > some other large open-source communities that I am personally involved > in, I feel that we're too closed. > > A developer recently compared Gentoo dev-ship to a marriage. In an ideal > world, sure, we'd love for every single person who makes any kind of > contribution to the project to become a full-time contributor who never > goes AWOL or sleeps with another project. But more realistically, I > think we need to become more open and flexible - as volunteers, people's > interests change, some people will stop contributing after they have > fixed whatever problem motivated them to contribute, etc. How can we > handle this better? > > We have a large expense on both sides when adding a developer to the > project. I personally have lost developer candidates, undoubtedly more > technically experienced than myself, who simply did not have the time to > go through a month-long recruitment process which involved studying > various documents not even relevant to the small area they would be > contributing to. On the other side, it's a fair expense to add a > developer to the project due to all of the > quizzing/assessing/account-creating/access-elevation/... > > Additionally, a significant percentage of developers who have joined > recently have gone AWOL after a few months. That hurts us, given the > expense we went through recruiting and adding them, and the time needed > to reverse that and retire them. > > I am not claiming this is an easy problem to solve - we do need to be > especially careful that any changes made do not decrease the quality of > commits to the live portage tree. This is why I am asking for help. > > I'm looking for ideas - preferably big, drastic, shiny ones. Ignore any > issues relating to migration away from our current system. What would be > the _ideal_ way for Gentoo to handle contributions from anyone? (note > that I'm dropping the user/developer community separation in that > question, as the boundary between those could change in these ideas) > How would an ideal recruitment process work, if there would be one at all? > > Please try and keep replies on-topic - I'm not trying to start a > discussion/flamewar on the current recruitment system or anything like that. > > To get you thinking, I suggest reading the section titled "Open > Development Team" at > http://www.samspublishing.com/articles/article.asp?p=23200&seqNum=3 > which is part of a (very good) larger article detailing why Linux kernel > development works so well. > > Any ideas?
perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev > Daniel > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
