Referrals could be helpful. I have no idea how one should properly contact a project, at least by email. Do I email the project/herd, the lead(s), somebody else in the project, or the gentoo-dev list first? I wish projects had a "Communications officer", someone(s) who is willing to be the appointed first point of contact for a project and be willing to receive unsolicited email, etc. and relay that to the rest of the project, if necessary, and so on. Anyway, I am getting into things we cannot change, so never mind.

In theory, that is part of the purpose of the User Relations project. In practice, it is typically a matter of some minor investigation to determine whom to contact and via what media, the process of which can be simplified by being a member of the project.

Yah, I was going to mention User Relations as well. It's honestly the best place to stop and get some help.

Email userrel@gentoo.org, or more simply hang out in #gentoo-userrel.

It is, sadly, a resource that is very, very rarely used, and the best way to get this kind of information._________________If it ain't broke, tweak it. packages | dvds | blurays | blog | wiki

The bug against devmanual for EAPI 2 has all the information. It's just a matter of getting it approved and merged in.

Thanks for the info. I did not mean to focus on EAPI. I was just fixing something at the time and I had to grep ebuild.sh, again. I knew about the pms overlay but not about app-doc/pms or zmedico's page. Also, I do not know much about (la)tex. I have not had the time to look into it.

beandog wrote:

Actually, you nailed it *right* on the head things that I'm trying to address. Any doc that covers "how to contribute" should also cover "how to actually contact someone."...

I noticed that some projects now have PR Liaisons. Maybe projects should also have a Userrel Liaisons or something like that. Maybe the PR Liaison can serve both needs. Having a dedicated person(s) for contact conveys the message "That person(s) is interested is hearing what you have to say and they probably have the time to get back to you more so than everyone else in the project."

Finally, I just want to say that "making it easier" to contribute, in part through more and better documentation is going to be great, but at some point actual developers are going to have to commit whatever to the appropriate trees. I believe the packages per developer ratio is going up and packages are being pushed to maintainer-needed under the stress. I think this is part of a larger, generic issue, and at this point I have no idea on what specific things, if any, can be done to address it.

The bug against devmanual for EAPI 2 has all the information. It's just a matter of getting it approved and merged in.

Thanks for the info. I did not mean to focus on EAPI. I was just fixing something at the time and I had to grep ebuild.sh, again. I knew about the pms overlay but not about app-doc/pms or zmedico's page. Also, I do not know much about (la)tex. I have not had the time to look into it.

beandog wrote:

Actually, you nailed it *right* on the head things that I'm trying to address. Any doc that covers "how to contribute" should also cover "how to actually contact someone."...

I noticed that some projects now have PR Liaisons. Maybe projects should also have a Userrel Liaisons or something like that. Maybe the PR Liaison can serve both needs. Having a dedicated person(s) for contact conveys the message "That person(s) is interested is hearing what you have to say and they probably have the time to get back to you more so than everyone else in the project."

Finally, I just want to say that "making it easier" to contribute, in part through more and better documentation is going to be great, but at some point actual developers are going to have to commit whatever to the appropriate trees. I believe the packages per developer ratio is going up and packages are being pushed to maintainer-needed under the stress. I think this is part of a larger, generic issue, and at this point I have no idea on what specific things, if any, can be done to address it.

For developer documentation, devmanual is the best resource. PMS is more for those who wish to write their own package manager or implement some part of it. This is a pre-built copy of PMS: http://dev.gentoo.org/~gentoofan23/pms/pms.html, but for writing ebuilds this is _not_ the resource you want._________________No Man is Just a Number!

This thread has become exemplary of the glacial pace at which Gentoo is currently moving. It was started on Wed Jul 30, 2008 by yngwin and after two whole months we still have nothing; no ideas, no action plan etc. Getting people involved is pretty easy, provided you have a clear working infrastructure. This is where DR does a good job (off course this another scale but still the same principles apply to Gentoo):

Quote:

Some quick updates:

Per request on this blog, I am now building ~pentium4 Funtoo (unstable) stages which can be downloaded here.

For the past few weeks, all my stage3’s have been about 15MB smaller than they were before due to the fact that I only build the en_US ISO-8859-1 and en_US UTF-8 locales by default. If you need to add any additional locales, edit the /etc/locale.gen file appropriately and then run the “locale-gen” command as root.

Starting with the October 1st ~x86 build, all Funtoo (unstable) stage3 builds now include dhcpcd and git. Gentoo stage3’s that I build do not contain any extra packages.

I have updated my git Portage repository at http://github.com/funtoo/portage/tree/master, and it now contains three branches - master, which has a README file and LICENSE file in it, gentoo.org which contains the official Gentoo Portage tree, and funtoo.org which contains the Funtoo tree. I’ve updated my wiki documentation so that it explains how to use it. The only part of the documentation that I haven’t updated is the advanced part that explains how to fork the tree. If you want to fork the tree on GitHub, I recommend creating your own branch. This is as easy as typing “git branch foobar.com” (your domain) with the funtoo.org branch active. I’ll update the docs with instructions on how to get your branch to show up on GitHub real soon now.

This thread has become exemplary of the glacial pace at which Gentoo is currently moving. It was started on Wed Jul 30, 2008 by yngwin and after two whole months we still have nothing; no ideas, no action plan etc. Getting people involved is pretty easy, provided you have a clear working infrastructure. This is where DR does a good job (off course this another scale but still the same principles apply to Gentoo): http://blog.funtoo.org/2008/10/funtoo-updates.html

I believe your entire post here is completely false. Ideas have been generated. Information has been gained. This thread is a discussion on why people aren't coming forward to be recruited and what could be changed. A discussion does not mean things discussed will definitely happen, and even if they do, they are not going to happen overnight. Things have come out of this thread - beandog has been working on a how to contribute article on Gentoo Wiki and from what I can see this discussion has helped the devs to better understand maybe why people aren't coming forward to be recruited._________________http://gentoo-wiki.com :: http://lug.org.uk :: http://www.linux.org/groups/ :: User Blogs

In the last days, I've seen some posts talking about a possibly lack of manpower in some Gentoo projects. One example is on a Gentoo dev blog, about KDE 4. However, I don't see the KDE project in the Staffing Needs Page. I think there are other examples : the press coverage page has not been updated since 2003, some pages are still linking to gwm instead of gmn, firefox 3 still not in stable branch, delay for 2008.0 release...

Before looking for solutions, I think the first thing to do is to find the reason(s) of this :

The recruiters themselves suffer a lack of manpower and cannot update the staffing needs page

some projects don't communicate their needs to the recruiters

there is not any lack of manpower : this is just temporary because developers don't have enough time to devote to Gentoo and more manpower wouldn't improve productivity

Do you, Gentoo devs, or guys who know more than me about internal functioning of the Gentoo project, have an idea about it ?

This thread has become exemplary of the glacial pace at which Gentoo is currently moving. It was started on Wed Jul 30, 2008 by yngwin and after two whole months we still have nothing; no ideas, no action plan etc. Getting people involved is pretty easy, provided you have a clear working infrastructure. This is where DR does a good job (off course this another scale but still the same principles apply to Gentoo): http://blog.funtoo.org/2008/10/funtoo-updates.html

I believe your entire post here is completely false. Ideas have been generated. Information has been gained. This thread is a discussion on why people aren't coming forward to be recruited and what could be changed. A discussion does not mean things discussed will definitely happen, and even if they do, they are not going to happen overnight. Things have come out of this thread - beandog has been working on a how to contribute article on Gentoo Wiki and from what I can see this discussion has helped the devs to better understand maybe why people aren't coming forward to be recruited.

Well it depends on your view of the goal of this thread. I take yngwin statement as the purpose and goal of this thread:

yngwin wrote:

... these are exactly the things I want to address with this thread. I need to take some time and gather the ideas here, and write up a draft document, and some proposals on how to improve communication channels.

_________________Please add [solved] to the initial post's subject line if you feel your problem is resolved. Help answer the unanswered

I've read most of the posts in this thread but maybe too quickly for many of them so sorry if I repeat some things.

At first, I would like to know if this thread is read by some Gentoo devs which have to power to change things or if we have to send a message to userrel@gentoo.org which AFAIK is the official email for suggestions (see User Relations page, chap 6).

Now let's come to the real subject. As others have already said here, there are many ways to help Gentoo (contribute or/and join the project). I don't know if there are too many ways, but at least it seems that it could and should be easier to help (contribute or/and join the project).

www.gentoo.org is the central point of the Gentoo community, and IMHO it is crucial that any visitor of the site can easily find a way to contribute or join (e.g. we could have a link "Join us" and a link "Contribute" in the top menu, like some guys have already said in the thread).

One of the link should target a page where you could learn all you have to learn to contribute (e.g. almost everything is in User Relations page, especially chap 5, but for now there is neither a link to this page from the home page nor from the top menu)

The other link should target to a page where you could learn how to become a Gentoo dev and what skills are needed. For now, most of these informations are in two different pages : Recruiters page and Staffing needs page. Only the second one is accessible from the left menu and I believe that something like "Join us" would be more eye-catchy than "Staffing needs".

Finally, if I consider that the lack of manpower is recognized, recruitment must be more effective. I strongly believe that it would be a simple first step to assign priorities to the staffing needs (which projects have urgent needs, which projects are more important...).

Some time ago, Tobias Klausmann (klausman) posted on the Planet that he was reviewing several version control systems as possible replacements of CVS for Gentoo. Is he working with a team on this, is there any progress? I am curious what the situation with that is.

Some time ago, Tobias Klausmann (klausman) posted on the Planet that he was reviewing several version control systems as possible replacements of CVS for Gentoo. Is he working with a team on this, is there any progress? I am curious what the situation with that is.

I know some people / developers would like to switch to git, but I'm not aware of any real plans to switch in the forseeable future. Before a swicth can even be considered someone would have to patch a number of tools to work with other version control systems than CVS (repoman, echangelog, emerge, ...) and give people time to test them out (you don't want to make a switch just to find out that half of your tools don't work anymore).

I know some people / developers would like to switch to git, but I'm not aware of any real plans to switch in the forseeable future. Before a swicth can even be considered someone would have to patch a number of tools to work with other version control systems than CVS (repoman, echangelog, emerge, ...) and give people time to test them out (you don't want to make a switch just to find out that half of your tools don't work anymore).

Standards Track GLEPs consist of two parts, a design document and a reference implementation. The GLEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the GLEP. Standards Track GLEPs must include an implementation -- in the form of code, patch, or URL to same -- before it can be considered Final.

So isn't the first step actually deciding to do the switch before doing any actual implementation?

So isn't the first step actually deciding to do the switch before doing any actual implementation?

It makes more sense in this case. Instead of just a fanboyish decision to switch to something else and *then* figure out how, they can do lots of research on how it would affect everyone and see if it's a good idea to switch and then provide it as an idea, and why its a good one.

Edit: Besides, antarus did a huge amount of research the other year for a Google SoC project and his write up is somewhere *too lazy to look*. The basic outcome was that there wouldn't be enough gain to offset the pain at the time._________________If it ain't broke, tweak it. packages | dvds | blurays | blog | wiki

Standards Track GLEPs consist of two parts, a design document and a reference implementation. The GLEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the GLEP. Standards Track GLEPs must include an implementation -- in the form of code, patch, or URL to same -- before it can be considered Final.

So isn't the first step actually deciding to do the switch before doing any actual implementation?

Well the implementation in this case would be the actual migration. What I was talking about isn't part of the migration itself, but a requirement for it (you can have the support without actually doing the switch, e.g. for overlays, but you can't switch without tool support).

Besides, antarus did a huge amount of research the other year for a Google SoC project and his write up is somewhere *too lazy to look*. The basic outcome was that there wouldn't be enough gain to offset the pain at the time.

I guess I will look for it.

Genone wrote:

Well the implementation in this case would be the actual migration. What I was talking about isn't part of the migration itself, but a requirement for it (you can have the support without actually doing the switch, e.g. for overlays, but you can't switch without tool support).

I see what you are saying. I would be interested to know what all the affected tools are, if it is more than just the three (repoman, echangelog, emerge), but it is not that important since no changes are planned.

I thought there might be some significant benefits to switching, but I have not done as much reading as antarus probably did and I am not as familiar with Gentoo internals.

You can also subscribe to the gentoo-scm mailing list which contains discussion a possible switch.

Thanks! I guess I may have to. I am interested to see what everyone thinks and this list is not available on the mail archive. What is proper netiquette for the mailing lists? Can/should users post, etc?

zaccret wrote:

... I strongly believe that it would be a simple first step to assign priorities to the staffing needs (which projects have urgent needs, which projects are more important...)

I do not know if you can really do that. It might lead to "My project is more important than your project" type of discussions, which could become unpleasant, at least. However, projects with multiple listings should be able to assign priorities within the project.

... I strongly believe that it would be a simple first step to assign priorities to the staffing needs (which projects have urgent needs, which projects are more important...)

I do not know if you can really do that. It might lead to "My project is more important than your project" type of discussions, which could become unpleasant, at least. However, projects with multiple listings should be able to assign priorities within the project.

I agree it is debatable. I think it would be nice for someone who wants to help the Gentoo project to know which are the most urgent needs.
However, priorites could also be assigned by the projects themselves (e.g. Documentation project could tell they hardly need a French translator because a lot of french pages need to be translated and they have a less urgent need for a German translator because a lot of german pages are already translated).

The first step wouldn't even be prioritising them - it would be getting more devs/teams to use them, and possibly featuring one team a month in GMN or something to spread the word a bit more. The GMN article could involve a detailed description from a member of the team about what sort of things they do day-to-day and how people can get in contact with them if they're interested in helping.

Also, there are some terminology items that could be changed that confuse people - herd and project (heck, even I don't know for sure which way round to use them) - as I understand one is a grouping of packages while the other is a grouping of developers. Perhaps "team" would be a better term for the latter. This might help people to find the developers they want to talk to more easily._________________http://gentoo-wiki.com :: http://lug.org.uk :: http://www.linux.org/groups/ :: User Blogs

Also, there are some terminology items that could be changed that confuse people - herd and project (heck, even I don't know for sure which way round to use them) - as I understand one is a grouping of packages while the other is a grouping of developers.