(Please do trim the subject line when it gets ridiculously long)
On Mon, 13 Nov 2006, Jon Phillips wrote:
On Mon, 2006-11-13 at 00:04 +0000, Alan Horkan wrote:
On Fri, 10 Nov 2006, Jon Phillips wrote:
Date: Fri, 10 Nov 2006 16:00:07 -0800 From: Jon Phillips <jon@...235...> To: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] [Fwd: [Inkscape-tracker] [ inkscape-Patches-1591723 ] patch to access potrace parameters within inkscape]
<snip />
Inkscape has been pretty good at marketing and gaining attention but converting that attention into new contributors is a tougher trick and not something most projects are good at.
The list of "Help Wanted" items Aaron Spike suggested is a phenomonally good idea.
I've been batting around a couple of ideas that we might be new ways to get developers involved in Inkscape.
Mission statement isnt the right word for it but it would be great if the idea of "contributors wanted" could be pushed harder so that every user evangelising Inkscape by word of mouth understands that more users is a secondary goal, only as a means to getting more contributors and to a lesser extent promoting the SVG standard.
I think we should ship with a basic task list and or add this to our about/help menu for easy access to new developers.
Sure in debug nightly builds include as much of those sort of things as you want.
Release builds however have a much longer half life. Applictions require lots of testing and the latest versions miss out on distribution deadlines, and older get left in distributions for months, even years with boxed versions. At University things got upgraded about once a year (or worse) so very often we were stuck with versions of software that were in excess of two years old.
Also, I wonder on what level we couldn't just say, "coming up next/soon in *THE NEXT VERSION 0.XX*, we need help with these 10 items on our roadmap, here is how you can help with these tasks.
KDE approaches this principle by identifying Junior Jobs (marked JJ in their bug tracker), tasks which could be implemented by new developers. Abiword used to run what were called Projects of the Week (POW) where tasks where highlighted to encourage new developers to get involved. These survived long after funding dried up but the management overhead required was difficult, especially since it was almost always easier for developers to fix things themselves than teach a new contributor to fix them. These tasks were usually things developers intended to work on themselves but they would specify the requirements first in the hope that someone else might try it and come back to it later and either help the new contributor or do the work themselves as originally planned.
Identifying tasks we "would like to have" but are low priority and which could easily be carried out independantly of and in parallel to Inkscape would be nice. For example I'm talking about tasks like support for new file formats, which although nice are fairly low priority and easily workaround by users. Ideally we would have a list of potential side projects available all the time much like the list of projects for the Google summer of Code.
Doesn't it seem like a great opportunity to put within our shipping software, requests for help, hooks for new developers, etc?
I think we should be looking at ways we can do what closed source apps can't do with these types of hooks.
OpenClipart.org should probably take another look at hooking into inkscape for that other type of contributor. I tried before to create a very basic pattern to advertise OpenClipart.org within Inkscape but perhaps a peice of sample artwork (in the form of a poster or flyer) or some kind of clipart related tutorial would be a good idea. Probably best to wait for the current artwork competitions to finish before pushing ahead with new ones though.
Ubuntu makes a big deal out of including a Translate link in the Help menu of every program. The Uncylcopedia page about Gnome Localisation should be required reading for all. http://uncyclopedia.org/wiki/GNOME_Localisation Technically it is satire but you can read it as a straight damnation of the horrifically convoluted process of translation and how horrifically confusing it is for most users and would be developers.
Before people start gushing over Firefox extensions I have to point out that lopping feature off of Mozilla and hoping people would reimplement them was very poor management which has resulted in lots of mediocre half finished extensions, and they had the luxury of a large user base to throw at the problem. The GNU Image Manipulation Program has resisted the temptation to similar throw out unmaintained scripts and plugins but it has gradually accumulated a whole lot of third party tools because everyone wanted to be included in the main distribution. In theory some fixes can be applied across all plugins but mostly it seems to be a whole lot more maintaince hassle. Seperating out extensions in a managed way and building up a strong collection of third party tools would be great and give new contributors a relatively easy place to get started but I'm not entirely sure how one goes about creating such a thriving community like that. I guess a stable platform is part of it, and an easy delivery system is another.
What do you all think about these ideas?
Well worth discussing in more detail. Hopefully others have seen successful ideas for involving new contributors from other projects they will tell us about, or perhaps tell us what little bit of help pushed them to make some of their earliest contributions.