Re: Lessons Learned
Unless, for example, you do this intentionally ;) Oliver On Sun, 12 Dec 2004 15:30:10 -0200, Felipe Leme [EMAIL PROTECTED] wrote: I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. -- Felipe On Fri, 2004-12-10 at 07:28, Danny Angus wrote: Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
On 12 Dec 2004, at 17:30, Felipe Leme wrote: I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. there is some truth buried somewhere in there... the time required to review, correctly and apply a patch is often underestimated. projects with too little available committer energy may get into a viscous circle whereby new committers cannot be recruited because there's too little energy to review patches. one way round this problem is to encourage users and developers to review patches submitted by others. it's also useful to try to do some sort of preliminary review and offer some kind words as soon as possible after a patch is posted even if work on the core project prevents a full review at this time. however, the quality of patches applied is crucial to the long term health of a project. reviewing and rewriting patches is the only way that developers are taught the standards required by the project. applying substandard patches shouldn't break the project in the short term (providing that it's adequately unit tested) but often produces headaches in the medium and long term. though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. the energy gained by recruiting a new committer (in this fashion) can easily be lost to the mentoring and refactoring required to produce code of the correct quality align with the goals of the project. IMHO it's almost always better (in the long term) for a developer to prove that they understand the direction and philosophy of a project by producing good patches which require no correction before they are elected a committer. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote: though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. I agree. I didn't mean that all patches, but they should at least be 'acknowledged'. Even a comment like 'this patch seems great, but I do not have time to carefully analyze it right now' would be better than simply ignoring it. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. -- Felipe On Fri, 2004-12-10 at 07:28, Danny Angus wrote: Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
robert burrell donkin wrote: beware too many organizational layers. flat is best. having a single sub-project with many releasables artifacts sharing the same community space (mailing lists, committer lists, voting eligability and so on) has proved more successful (see jakarta commons) than a complex web of sub-sub-sub-projects. factor along community lines: groups working on different releasables being unhappy about sharing the same community space is a good sign that they are two separate projects. (most modern email clients have good filtering support so provided conventions are adopted, several different code bases can be easily support on a single mailing list. for those unwilling or unable to set up filters, using a news reader and www.gmane.org works well.) +1 Don't be afraid of forks or duplication. If someone wants to try something out on their own, let them. But that doesn't mean you have to host it in the original project. There's plenty of space for similar and even competing software projects. A single project does not have to be everything to everyone. Some other lessons I learned in working with Apache Avalon: http://www.jadetower.org/muses/archives/000146.html jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
