On 23 December 2010 13:24, David Cole <david.c...@kitware.com> wrote: > How do we make it very hard? What about KDE and Homebrew make this very > easy? Specifics, please.
Firstly, http://producingoss.com/ is a great read. Specifically though, Homebrew is pretty much the golden child of encouraging external contribution. We're the most forked repo on Github, the 6th most watched and have had 719 code contributors in about a year and a half of existing. We've managed this with only 4 people with commit access, all of whom have full-time jobs in the industry working on other projects. I think Github and DVCS really allows you to scale well. If you publish decent guidelines for how people can contribute and use e.g. pull requests on Github or similar Git mechanisms then you can have incredibly quick workflows for viewing, mergeing, testing and pushing user code. I have an alias "bpi" in my shell which downloads from a pull request or user repository commit on Github, applies it to my local repository, shows me the changes and installs the relevant changes packages. Once I type "git push" this is now shared with everyone using the project. I think for you guys general guidelines on what patches would/wouldn't be accepted would be a good start. Documentation of your coding standards and what I should do to test my work before submitting it would help too. I can guess a fair amount because I've contributed to a lot of open-source projects but others might not do the same. I think the main thing that I find lacking here though is responsiveness to suggestions. When I make one, I need to keep poking again and again until I receive I response. Other things include specific code review of patches and a quick "this functionality would/wouldn't be accepted" when suggestions are made so I know whether to work on it or not. I think using Git/Github in your workflow could help with part of this but a certain amount will need to be responding to users, either through your current bug tracker, a better one or Github's issue tracker. Another option that might help is a cmake-dev mailing list that is only for discussing development issues rather than users seeking help. Just a few ideas for you. Hopefully some of them are useful. I'm more than willing to discuss this in further depth, either here, personal mail or at an open-source conference (next one I'll definitely be at will be the KDE one in Berlin 2011). > Thank you. Even with more external developers, I think we'll struggle -- > that would just be a different sort of struggle. Sure, it will probably involve more reviewing/mentoring but less code writing. > Again, let me stress, no offense taken. There is no way you can offend me, > unless you start calling me names for no reason. Reasonable discussion > always welcome. So can I call you names as long as I have a good reason? ;) -- Mike McQuaid http://mikemcquaid.com _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake