(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.

On Mon, 2006-11-13 at 08:21 -0600, Aaron Spike wrote:

We've had todo lists, janitor lists, and a roadmap for a long time. They are all wonderful tools but from my point of view they haven't attracted many contributions. (Not to minimize the contributions that have come by way of these lists!) I'd like to do more to put these items in front of people. My first goal is to be more faithful in sumarizing happenings on the dev list in the inkscape.org news. My hope is that by increasing the techiness of the news we can attract more techies.

Does anybody have any idea how many places syndicate the inkscape.org front page news? Any ideas how we can up the count?

Aaron Spike

Bryce can point you to it...yes, we need way more news and publicity (and more releases to garner more publicity IMO)

Aaron, would you like to help me on this "hook" strategy?

I think we need to be three-pronged:

1.) front and center on the inkscape.org site, list out top feature requests desired with various levels of skill required

2.) list this inside inkscape as well, or at least link to this list within the menu

3.) cross-promote Inkscape's needs on other sites (openclipart.org, scribus, etc)

Thoughts?

Jon

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.

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.

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.

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.

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.

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.

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.

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%. ;-)

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.

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.

Bryce

I could tell the same of you Aaron : oh not for the user_manual that i've begun the first days of Inkscape (bacause i was doing the one of Sodipodi) but on explaining some pythons extension rules, get some time answer my question, you gave the possibility to do some. Many devs behave as you (jon, Bryce, bulia,...) but some others are more elusive. And that is not enough for a beginner or a person that is feeling himself as a bad coder.

Other thing is that i agree core coding of inkscape a the most important thing, but we should not forget that Inkscape is made for users and that many contribution has to be done in that direction : - documentation (i do a french that i translate to english, but surely not well and it could made in other languages) : i'll recontact R. Joost (Gimps user_doc) that i met during LGM to know what we can improve in that - UI and translation - sample docs

In fact, as mentionnes by bryce, when the number of contributors is increased the time needed to manage them is also growing. If that is coming one day, may be we could take a look at OpenOffice management, because they're used to deal with many contributors of different kind.

pygmee

This has been a huge help for me. Thank you to Bulia and every one else who has taken the time to explain projects to me over and over. I feel like I've gotten some really useful stuff implemented working off your notes and I've learned a lot in the process.

Aaron Spike

---

Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Tue, Nov 14, 2006 at 07:48:14PM -0800, Jon Phillips wrote:

...

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.

yes, majorly!

...

...

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 many people.

...

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?

Ok, Bryce, this is an awesome list. Lets put some of these into a plan of action. What do others think?

Here's some thoughts on plans around the paint by numbers idea...

1. Select (say) 3 areas in the codebase to focus on, that + There are many bugs/rfe's of relevance + Core developers think are important to be worked on + Won't be too intimidating to novices + Several people already understand moderately well

2. Write up a few paragraphs describing what our objective is, and how to define a "paint by numbers" project.

3. For each area, create a short guide page that collects tips, tricks, links to more info, contact persons, etc.

4. Assemble listings of bugs/rfes in each of the target areas + Group by topic, filter out top priorities, sort by difficulty + Identify ones to be turned into "Paint by Number" projects

5. Recruit the people who understand the areas + Explain what the goal is - getting more developers involved + Email them the stuff from #2 + Ask if they could go through one section of the above list and describe the steps to be taken + Mark items as ready once someone's described them

6. Invite new developers to help undertake the projects + Write posts on our PR channels identifying cool tasks + Recruit from past patch contributors + Recruit from newbies on mailing list or irc channels + Point interested people at the info from #3 + Follow up with them to see if they've run into any issues you could help them with

7. Give thanks to each person who participates

Bryce

On Tue, Nov 14, 2006 at 08:39:38PM -0800, Bryce Harrington wrote:

...

Ok, Bryce, this is an awesome list. Lets put some of these into a plan of action. What do others think?

Here's some thoughts on plans around the paint by numbers idea...

1. Select (say) 3 areas in the codebase to focus on, that
   • There are many bugs/rfe's of relevance
   • Core developers think are important to be worked on
   • Won't be too intimidating to novices
   • Several people already understand moderately well

In hopes of sparking some discussion, here are some different areas we could pick from:

* Guides, rulers, snapping, and grid * Inkscape Internal API - DOM/verb work * File format converters * Code cleanup - InkscapeJanitors * Gtk/gtkmm goofiness * Renderer bugs * Text and fonts * Whiteboard * Printing

Which three of these sound most interesting to make paint-by-number things around? All of these have a lot of bugs/rfes associated with them, and work in these areas would move Inkscape forward.

Bryce

On Fri, Nov 17, 2006 at 02:32:30AM +0300, Alexandre Prokoudine wrote:

On 11/17/06, Bryce Harrington wrote:

...

Which three of these sound most interesting to make paint-by-number things around? All of these have a lot of bugs/rfes associated with them, and work in these areas would move Inkscape forward.

According to my own experience of talking to users, these ones:

• File format converters (people are _begging_ for CDR import)
• Renderer bugs (same)
• Printing

True, although I was wondering more along the lines of what would novice developers find interesting to work on.

Bryce

On 11/17/06, Aaron Spike wrote:

Alexandre Prokoudine wrote:

...

As for file formats, we have a contributor who is working on an ai2svg Python script. One of core team members (don't remember who exactly) promised to have a look at it.

http://sourceforge.net/tracker/index.php?func=detail&aid=1533789&gro...

That was me. I looked. I fixed a couple little bugs, but I got to one I'm not sure how to fix. Is the author still willing to work with me on this?

I bet he is :) CCing him this email to make sure.

Alexandre