On Tue, 2006-11-14 at 19:23 -0800, Bryce Harrington wrote:
> On Tue, Nov 14, 2006 at 07:04:45AM -0600, Aaron Spike wrote:
> > Jon Phillips wrote:
> > > Bryce can point you to it...yes, we need way more news and publicity
> > > (and more releases to garner more publicity IMO)
> I've put a lot of thought into how we can increase the number of
> contributors to the project. I've got some ideas, which I'll enumerate
> down below...
> But first I should mention that I think raw PR by itself - while
> important and useful - is not sufficient for getting development work
> done, and has some risk of being counterproductive. I actually think
> Inkscape has been doing fine at getting visibility (both with formal
> PR and word of mouth). But as a tool for getting contributors,
> publicity is sort of a two-edged sword: For every new contributor we
> get, we also gain increased usership with the correpsonding increase in
> labor to support them (answering questions, handling bug reports, etc.)
> Also, we can expect that new users will stick around and continue to
> require support, whereas new developers may or may not stick around;
> thus publicity could actually end up increasing the workload on existing
> developers, rather than offloading them.
Yes, this is true. I am not advocating raw PR, which is good to get us
more visits and news, but not necessarily developers who want to
contribute to the project.
> I think that we probably actually get a fair amount of "passers by" who
> _could_ contribute, but for one reason or another don't. Some possible
> reasons they might have:
> * Feel that they don't have...
> - adequate coding skill
> - knowledge of inkscape internals
> - time
> - authorization
> - an itch to scratch
> * Perceive there is insufficient "ego gratification"
> - Want full authority over their work
> - Want recognition/respect
> * Fear of having work critiqued/rejected/ignored
> - Embarrassment
> - Worry of being shut out
> - Risk of wasted time
> - Risk of arguments
> * Assumption that other developers will get to it eventually
> - Feel their time is best spent on other priorities
> - Seems like an obvious need, surely someone will get to it
> - Posting a bug report seems "good enough"
> So, the key to gaining more developers is to find ways to solve or work
> around these concerns. Fortunately, many are just misconceptions.
> Here are ideas:
> 0. Invitation to participate
> The most effective way to get people involved is just to give them an
> invitation to try implementing it themselves. E.g., I often ask, "Can
> you code? Why don't you give it a shot?"
> I thing this approach shortcircuts a lot of the above worries or
> something. In any case, it's easy to do, and it seems to work more
> often than not for Inkscape.
> Be sure to make it a friendly, open ended invitation to do something
> they have a strong itch to do. Avoid pressuring them or imposing
> expectations - this can just scare them away.
> Note that invitations can be directed at old developers as well as new
> ones. Sometimes expressing interest in something the old developer was
> working on, plus encouragement to continue can be enough to stimulate
> them to do more.
Yes, this is great. Also, a nice personal touch to this communication
helps, as Bryce and I have noticed...make sure to explain how to help
rather than just a link dump or pointer to a sole wiki page...
> 1. Newbie training program
> Organize a structured education effort where novices can learn and
> practice skills in a comfortable environment, where risks are low, and
> where they feel they are gaining something tangible for their time.
> This would require core developers to devote some time to teaching,
> which includes preparing training material, designing projects,
> answering questions from students, and doing evaluations.
> In exchange for the training, the student would be expected to complete
> one or two class projects. These projects would be geared towards
> solving real Inkscape bugs or rfes.
I could see how we could do this with extensions and some basic coding
in the app. Is anyone interested in this and/or helping with this? This
one has a larger time committment, but possibly higher returns.
> 2. "Paint by Number" projects
> I think the reason our roadmaps, bug/rfe trackers, etc. haven't worked
> at getting more people contributing, is because oftentimes the procedure
> for doing the fix or implementation is extremely obscure.
> >From my own personal experience, the codebase can be quite difficult to
> understand until someone gives you some clear guidelines. Sometimes 90%
> of the effort is just figuring out *what* to do.
Yes, especially with all the migration and refactoring going on...
> But if an experienced core developer put in 1 hour just describing how
> to do a task, then later someone with less experience could use that
> description as a map to doing the solution.
Yes, especially with really big tasks...this outline would help many
> It may seem that this would be inefficient - it may take less total
> manpower for the developer to just do the work directly. However,
> for the core developer, they could probably outline several tasks in the
> time it'd take them to complete one. Even more importantly, the end
> benefit is that the new developer gains expertise that may enable them
> to contribute more in the future.
> IOW, "Give a man a fish, he'll eat for a day; teach a man to fish, and
> he'll eat for a lifetime."
> An interesting experiment would be for a core developer to spend a day
> going through bugs or rfes and rather than investigate them, to simply
> describe the steps they themselves would take to do it, and encourage
> others to give it a shot. Then later look back and count how many of
> the tasks were able to be completed by someone else. I bet we'd see a
> large net gain.
I agree...I wish I knew the complete codebase better, but will start to
do more on the tasks I could do. Others, what do you think? Maybe we
could make a day for this...like the day of painting by numbers and just
use this as our general strategy for bugs for devs. Thoughts?
> 3. Code documentation
> As mentioned in the previous item, just figuring out *what* to do can be
> the bulk of the challenge. Inkscape's rather sparse code documentation
> tends to contribute to this problem.
Yes, we need better documentation in our code...is anyone interested in
helping with this?
> I make a habit when studying the codebase, to add comments for each
> function I go through, to describe what it does and what its inputs and
> outputs are. This helps me because I have such a crappy memory, but
> also it should end up helping decrease the amount of work others need to
> figure out what to do. Maybe reducing the effort from 90% to 80%. ;-)
Yes, completely agree...this is a good guideline too...
> 4. Break functionality out into libraries
> With any coding project, the sheer size of the codebase can pose a
> hinderance to looking under the hood. The more code, the more
> intimidating it must seem to a potential new developer.
> A possible solution to this is to move core code out into separate
> (either new or existing) libraries. In addition to reducing our core
> linecount, libraries can have better defined interfaces. It can also be
> given sufficient independence from the core codebase that it satisfies
> the need for control that some desire.
> A good general purpose library could be shared between multiple open
> source projects, and in theory would be able to pull in contributions
> (or at least ideas) from a wider group.
> Of course, there are a whole host of trade-offs to having code in a
> separate library, so it is important that this be undertaken only if
> there are dedicated developers and clear boundaries.
Yes, we need to re-examine this idea again...Bryce, you remember our
inkcore concept? Yes, with lib2geom, cairo and more, it would be great
to get our librarification plans sorted out again.
> 5. Emergency calls to action
> I put this one last because while can work, it's pretty snarky. As they
> say, sometimes it's the squeaky wheel that gets the grease, so sometimes
> in order for a wheel to get greased it first has to get a lot squeakier.
> Thus, sometimes putting out complaints about how terrible something is,
> and how it is being completely ignored, can be effective at drawing
> people in - particularly 'firefighter' style personalities who like
> being the hero. Or threaten to take some undesireable alternative
> action (like closing the project, dropping a buggy feature, etc.)
> There is often some political price you must pay for taking this
> approach: Threats can engender bad will; forcing decisions can risk
> alienating key developers; making demands can make you seem like a
> tyrant. Also, there is always the risk you will be seen as "crying
> wolf", and future calls you or others make may simply be ignored.
Yes, it is good to mention, but we should stay away from these because
nothing nor person is dying, so its not really an emergency, right?
Ok, Bryce, this is an awesome list. Lets put some of these into a plan
of action. What do others think?
San Francisco, CA
USA PH 510.499.0894
MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon@...