I didn't mean to suggest that projects like the Linux kernel don't have suitable tasks for beginners, just that they wouldn't obviously benefit from being more accommodating to beginners; however if they really don't have things for beginners to do, that would suggest that there's no point in their becoming beginner-friendly. I am doubtful, however, that these large projects have little for beginners to do.
The idea that tiny patches should be welcome is not a surprise; what is is your implication that some projects don't welcome them. Most of the patches I've submitted to GNU projects to which I'm not an active contributor have been tiny, and most of them have needed revision. Nonetheless maintainers tend to encourage them because the effort of reviewing them still often outweighs the effort of writing them, and I've never felt that tiny patches are unwelcome (although just as often when I report a problem needing a tiny patch the maintainers will find it easier to make the fix themselves without involving me).
Your point about creating an atmosphere in which new contributors do not feel "judged or shamed if they get something wrong" taken together with your disagreement with my assertion that cluelessness is a form of rudeness to help me explain what I was trying to say. You address the culture gap between experienced contributors and newcomers, but I would offer an alternative view of the responsibilities of both sides.
You say: "It really doesn't take that much more time to type out something like '[a short paragraph]' than '[a short line]'". Oh, but it does, and that's precisely the problem. Experienced contributors have, as I wrote before, other responsibilities than to new developers, and one who goes so out of their way to be friendly may well do so to the detriment of their other responsibilities. One of the nice things about the lack of face-to-face contact in internet-mediated projects is precisely that one can much more easily avoid the ego's distractions in a technical argument. This applies equally to reading as to writing without malice. You suggest this comes as a rude shock to nervous newbies. I offer that the problem is as much on the newbie's side: in cyberspace, there are none of the physical trappings of authority that suggest to the ephebe that bothering the queen about something small on his first day might be a bad idea. When you enter a new world, you have to expect to put some work in and learn its rules, and to be told to start with that you're making mistakes. Perhaps cyberspace makes this harder just as it makes it easier for the experienced to rub along almost frictionlessly.
In summary, I agree that one could reasonably look for a few more well-chosen words of encouragement from the experienced, but that it should be only a few; in particular, newcomers have, I think, to learn not to feel insulted when they are politely directed by a cut-and-pasted paragraph to please go and read a few introductory documents.
There's also the question of media: asking dumb questions in an IRC channel is much better than posting to a mailing list, as IRC is a transient and generally more relaxed medium than email, whereas a developer reading babble in a mailing list will often feel both that one of the central records of the project is being filled with junk, and that their time is being wasted when they're trying to get things done. It's an online analogue of trying out a mad idea at the water cooler before raising it at a board meeting.
One last comment on rudeness online: I find it particularly rare, I must say, and further that it rarely comes from major contributors, but typically from wannabees who are themselves insecure. Again, it's easier to recognise and deal with in face-to-face contact than online.
It's quite possible that the generation of teenagers just entering the world of free and open source development now will, by virtue of having grown up with online media, actually have fewer problems understanding all of this, and that the part of the problem that is down to real-life vs cyberspace misunderstanding will go away. Of course, most of the cultural problems that beset meatspace will remain; I have no illusions on that score!
Your questioning of what determines what is "useful" in a project is interesting, but I don't think it changes my argument: the primary goal of a free software project should be to fulfil its notion of utility, whatever that is. In some projects, of course, that could be nothing to do with the software produced, as in a collaborative exercise in a classroom situation.
It took me a long time to feel I could contribute to projects too, but that was mostly over a period before I had internet access, so it could have been mostly down to the barriers to communication.
The dynamics of participation in pretty much any community come down to the interplay between what you put in and what you get out, and uneducated human nature tends always to emphasise the latter. I think therefore that the best way to sum up my argument is that I stress "education" rather than "nurturing", understanding that the former encompasses the latter, and leads to a better vision for communities of any kind.
Re: Good ideas, wrong target?
The idea that tiny patches should be welcome is not a surprise; what is is your implication that some projects don't welcome them. Most of the patches I've submitted to GNU projects to which I'm not an active contributor have been tiny, and most of them have needed revision. Nonetheless maintainers tend to encourage them because the effort of reviewing them still often outweighs the effort of writing them, and I've never felt that tiny patches are unwelcome (although just as often when I report a problem needing a tiny patch the maintainers will find it easier to make the fix themselves without involving me).
Your point about creating an atmosphere in which new contributors do not feel "judged or shamed if they get something wrong" taken together with your disagreement with my assertion that cluelessness is a form of rudeness to help me explain what I was trying to say. You address the culture gap between experienced contributors and newcomers, but I would offer an alternative view of the responsibilities of both sides.
You say: "It really doesn't take that much more time to type out something like '[a short paragraph]' than '[a short line]'". Oh, but it does, and that's precisely the problem. Experienced contributors have, as I wrote before, other responsibilities than to new developers, and one who goes so out of their way to be friendly may well do so to the detriment of their other responsibilities. One of the nice things about the lack of face-to-face contact in internet-mediated projects is precisely that one can much more easily avoid the ego's distractions in a technical argument. This applies equally to reading as to writing without malice. You suggest this comes as a rude shock to nervous newbies. I offer that the problem is as much on the newbie's side: in cyberspace, there are none of the physical trappings of authority that suggest to the ephebe that bothering the queen about something small on his first day might be a bad idea. When you enter a new world, you have to expect to put some work in and learn its rules, and to be told to start with that you're making mistakes. Perhaps cyberspace makes this harder just as it makes it easier for the experienced to rub along almost frictionlessly.
In summary, I agree that one could reasonably look for a few more well-chosen words of encouragement from the experienced, but that it should be only a few; in particular, newcomers have, I think, to learn not to feel insulted when they are politely directed by a cut-and-pasted paragraph to please go and read a few introductory documents.
There's also the question of media: asking dumb questions in an IRC channel is much better than posting to a mailing list, as IRC is a transient and generally more relaxed medium than email, whereas a developer reading babble in a mailing list will often feel both that one of the central records of the project is being filled with junk, and that their time is being wasted when they're trying to get things done. It's an online analogue of trying out a mad idea at the water cooler before raising it at a board meeting.
One last comment on rudeness online: I find it particularly rare, I must say, and further that it rarely comes from major contributors, but typically from wannabees who are themselves insecure. Again, it's easier to recognise and deal with in face-to-face contact than online.
It's quite possible that the generation of teenagers just entering the world of free and open source development now will, by virtue of having grown up with online media, actually have fewer problems understanding all of this, and that the part of the problem that is down to real-life vs cyberspace misunderstanding will go away. Of course, most of the cultural problems that beset meatspace will remain; I have no illusions on that score!
Your questioning of what determines what is "useful" in a project is interesting, but I don't think it changes my argument: the primary goal of a free software project should be to fulfil its notion of utility, whatever that is. In some projects, of course, that could be nothing to do with the software produced, as in a collaborative exercise in a classroom situation.
It took me a long time to feel I could contribute to projects too, but that was mostly over a period before I had internet access, so it could have been mostly down to the barriers to communication.
The dynamics of participation in pretty much any community come down to the interplay between what you put in and what you get out, and uneducated human nature tends always to emphasise the latter. I think therefore that the best way to sum up my argument is that I stress "education" rather than "nurturing", understanding that the former encompasses the latter, and leads to a better vision for communities of any kind.