On 14/02/2011 18:55, Yaron Koren wrote: > Hi, > > These are interesting links, with some useful tips - I'll definitely try > to respond to patches soon after they're sent, instead of (as sometimes > happens) a few weeks later.
Yes, this one aspect of answering quickly may have a huge impact on the success of a project. In particular, it may determine whether or not a potential contributor decides to stick with the project or not. I think we are not too bad here (thanks also to the many people contributing to this list!), but there is always room for improvement. > > The roadmap stuff is interesting, too. What's there isn't completely > relevant to SMW, since that guy is coming from the perspective of > projects like GIMP and Inkscape - basically clones of existing software, > where the set of needed features is (fairly well) agreed on ahead of > time, so the roadmap can include dates and start to resemble a future > release schedule. In our case, we're in uncharted territory - no one can > say for sure which features will be useful and which won't, or what the > best solution is to a given problem. Our roadmap is more like a "to-do > list", which I think is the right way to go for us. > I agree. Roadmaps for smaller projects like SMW are always somewhat harder to maintain. > Having a set of independent projects for people to work on could be > useful. It might make sense to just do that as part of the existing > roadmap page - we could have asterisks next to tasks that could be done > as independent projects. Fixing the security leak in the 'ploticus' > format, for instance, is something a new developer could do (assuming it > can be done at all). And there are a bunch of smaller tasks that I (and > others) haven't even put on the roadmap page, since it seemed to be more > about providing a high-level overview than creating a task list. But > having a single page seems to make more sense than having two pages with > some overlapping contents. Not sure if the "big" goals in the roadmap are compatible with the smaller kind of starter's project. Having both on the same page might be a good start, but I can imagine that the content and format of a "project suggestions" list is quite different from the roadmap (project suggestions need more details, starting points, hints). But having anything at all would be useful to start with. - Markus > > On Sat, Feb 12, 2011 at 11:07 AM, Markus Krötzsch > <mar...@semantic-mediawiki.org <mailto:mar...@semantic-mediawiki.org>> > wrote: > > Some insightful comments on how to grow and sustain contributor > communities in OSS: > > -------- Original Message -------- > Subject: [Wikitech-l] Roadmaps and getting and keeping devs > Date: Sat, 12 Feb 2011 16:55:34 +0000 > From: David Gerard <dger...@gmail.com <mailto:dger...@gmail.com>> > Reply-To: Wikimedia developers <wikitec...@lists.wikimedia.org > <mailto:wikitec...@lists.wikimedia.org>> > To: Wikimedia developers <wikitec...@lists.wikimedia.org > <mailto:wikitec...@lists.wikimedia.org>> > > These have been circulating in the open source Twitterspere today. > They struck me as apposite to discussions on these topics around > MediaWiki. > > How to write a roadmap: > > http://blogs.gnome.org/bolsh/2011/02/07/drawing-up-a-roadmap/ > > How to grow your contributor community (and how to decimate it): > > http://www.codesimplicity.com/post/open-source-community-simplified/ > > > - d. > ------------------------------------- > > Not always applicable to all of our (sub)projects, but we can surely > take some things from this. Two things from the second link that SMW > should concretely improve (in co-operation with all extension projects): > > (1) A list of easy starting projects (nothing there right now). > > (2) Excellent, complete, and simple documentation describing exactly how > a contribution should be done (largely incomplete, and focussed on > general hints/rules/warnings but not on concrete contribution paths). > > It might be worth thinking about how this can be achieved. (2) could > help all SMW extensions if placed visibly on our homepage (with pointers > to extensions that welcome new contributors). (1) could allow more > "non-critical" features (that are fun for newcomers) to get implemented > at all (the core devs tend to focus on bug fixing and large-scale > projects). In our case, this could also be a list of projects that could > be done as mini-extensions. > > I recall having similar discussions in the past, but our start page > clearly lacks the big fat "Contribute" button with easy first steps. > Contributions are welcome ;-) > > Cheers, > > Markus > > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel > Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > <mailto:Semediawiki-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
