On Fri, Apr 04, 2014 at 07:11:13PM +0200, tavmjong@...8... wrote:

Hi all,

We had a very good meeting this morning. Nine (9!) Inkscapers were present (partially thanks to the Inkscape development fund). Here is a list of those present:

Martin Owen/doctormo (barcode extension, Python, C++) Joakim Verona (artwork, Inkscape with emacs, d-bus, interest in embedded Inkscape) Krzysztof Kosiński (Clipboard, Cairo renderer, boolean path operations) Gémy Cédric/pygmee (extensions, Python, documentations) Sirko Kemter (LGM Host, Inkscape trainer) Elisa de Castro Guerra (documentation, translations) Ryan Lerch (Redhat user) the Adib (translation, Cairo, interest in PDF output) Myself

Here are some notes I took from the session merged with some notes from Elisa (thanks!). We covered a lot of stuff. Let me appoligize to those present if I get some details mixed up.

Thanks for writing up these notes!!

1. Community Development

   The Inkscape community appears to be quite weak compared to other projects. We discussed a variety of reasons for this and possible solutions.

On my return to Inkscape last year, this struck me as well. It has lessened in number of active members from how it once was way back when. But those involved seem even more dedicated and hard working, so we have a really strong core we can build from, which makes me very enthusiastic about the future.

• The community appears to be quite fragmented due to multiple websites for code, bug-tracker, mailing lists, forums, etc. We should consolidate where possible. There could be better linkage between sites. The Inkscape website still needs to be expanded. For example, there is no page for translators (already fixed since our meeting, thanks Elisa and Martin!). Also, we need make sure that feature requests in the Inkscape forums get aggregated to the developers email list. Martin will try to find someone to volunteer to act as liaison.

Good suggestions. Especially now that we have a new website design and structure, it would be good to make it into a more comprehensive resource. I'm unsure to what degree this would actually stimulate more community involvement, but it couldn't hurt and it'll at least standardize things better on the sysadmin side.

Regarding feature requests, it would be nice to set up sort of a "pipeline", that aggregates and evolves these into workable project plans. So for instance, at one end is a user-friendly "suggestion box" type interface that makes it trivial for anyone to send in ideas and requests. Behind that would be some kind of service or tool that enables us project folks to sort through these, mark/discard duplicates, and aggregate similar requests together. The third layer would allow crafting design and implementation proposals, which could then be fed into a) janitors page, b) GSoC ideas page, c) project roadmap, and d) fundable projects list as appropriate.

• There appears to be a lack of direction. The Inkscape board is, by design, limited to controlling Inkscape's donations and trademark. Having some kind of steering committee might be beneficial.

Right, technical decisions are not the jurisdiction of the Inkscape board.

Certainly a technical board is a possibility, and I have ideas on how we'd go about setting one up, however I'm not sure that's the ideal solution here. Reason being is that the number of people doing active development in the project is not really *that* large. It'd be hard to assemble a technical board which wasn't just a mirror copy of everyone already active on the list. :-)

So I think we need to look more at why there appears to be a lack of direction. Is it because there are too many different ideas on how to do things, and lack of consensus to move forward? Or is it because there's a lack of a plan for where we want to go in the near/mid/long term? Or is it because of something else?

• There is a lack of visible momentum in the project, exasperated by the long time between current releases. (We desperately NEED to get 0.91 out - as well as 0.48.5. People need to see progress.) More news articles are needed (with rapid translation).

Agreed. I think more frequent releases will have the biggest impact on community involvement. I'm going to try to make my main area of focus to just keep the release moving forward, with whatever time I can scrape together each week.

My hope is that once we have a good solid 0.91 release under our belt, we can pump out 0.92, 0.93, etc. in rapid succession. To do this, we'll need to keep QA processes and tools in active use to prevent regressions from creeping in.

• Paid developer: Synfig hired a developer who is now paid month-to-month by crowd-funding. This has actually stimulated additional developer contributions. People see progress being made and are more likely to make their own code contributions. There are weekly updates by the developer where people see the progress being made. (This is in contrast to the prevailing view inside the Inkscape community where paid development might threaten further contributions by non-paid developers.) Blender uses a subscription system. Many communities use a voting process to select the direction of paid development. We do need to be careful, as Scribus had a bad experience with a paid developer disappearing without delivering promised code.

Unfortunately at this point we simply don't have sufficient income to afford a full time developer. I hope to get our Funded Development plan published this week, in hopes we can at least get some bounty-style piecework development going. Maybe if we see big successes with fundraisers we could entertain employing parttime or fulltime developers or coordinators, but best case that's going to be down the road a bit.

• Extensions is a place where people can easily make contributions. We need a web page with links to contributed extensions (or host them ourselves). (BTW, Blender had 8 part-time developers but still has a very active community of people contributing extensions.)

An amazing amount of work has been achieved with Inkscape's extension system. At some point here I think we should investigate scaling it up, perhaps by establishing core / extra / contrib extension repositories, or perhaps alterations to the API or architecture of our extension system to enable them to be more powerful. Anyway, a discussion to have for the future.

2. Paid developer

   We discussed what we would want a developer to do if one were hired. Ideas were:

• Animation (high profile, improve sense of forward momentum).

• PDF Export (same as above).

• Plug-in structure (make it easier to contribute).

• Code clean-up and documentation (make it easier to contribute).

• Release (get timely releases out).

• Testing

Animation and Plug-in - You know, based on my experience so far in open source, structure are the type of "sexy features" that volunteer developers would love to sink their teeth into, if an overall plan of attack was laid out that they could follow. As well, each would likely have rather far reaching implications to the code, and likely would need changes in many places including some UI overhaul; thus it'd necessitate lots of buy-in and consensus building for collaboration -- IMHO FOSS is able to do this type of change work way better than paid development.

PDF Export and various other features relating to PDF and print in general seem to be less enticing of volunteers, and so might be more appropriate for paid work. In our codebase these also tend to exist in more compartmentalized sections of code that fewer people are going to expect to have a say over, so paid developers would likely find us less of a headache to work with.

Code cleanup, documentation, and testing are good ideas for paid development, as they tend to be compartmentalized, require little or no collaboration or consensus, don't require as extensive knowledge of internals, and have easily measured status. On the other hand, for all these same reasons, these all tend to make good janitor tasks for newbie volunteers. So it might be more cost effective to seek volunteer janitors for them. (Indeed, one of the challenges for bringing in new developers is to provide easy bite-sized tasks to work on, and these three areas tend to be excellent sources for that.)

Release is an interesting beast; there's essentially three chunks - One is the organization/coordination/planning bit, generating/signing the tarballs, marketing, and translations. This is all fairly straightforward work, but can be rather monotonous. However, it lends itself to scripting, so the more often you do it the easier it gets. Second is "showstopper bugs"; these are often in areas that specific people have been making changes in, that don't lend themselves to 'throw more manpower at it' - they require a specialist to spend time sorting it out. Packaging work tends to fall into that category as well. Third is general QA and bug fixing (e.g. our bug hunt). So, the first and third sections could benefit from paid workers, but it's really the second section where our release process runs into the most pain, and I'm skeptical that paying people would get it done any faster.

3. Website Translations

   Several problems were identified with translating the website. Translated news is being shown twice, once in the translated language and once in English. Martin and Adib will look into fixing this (some python coding). Also, translators are not notified of news updates. Martin will assemble a list of translators and set up a "cron" job to monitor changes to the website and then notify translators when changes are detected.

Good to hear progress being made here.

4. Technical discussions:

• 0.91 release: We need to get this out, even if there are a few remaining bugs. Adib will help with Windows builds. There is great demand for a GTK3 OSX build. It seems that the only hold-up is redoing the rulers as GTK3 dropped the ruler widget. Gimp has the same problem.

Has the GTK3 OSX need been met by now, or is this still an open issue? If the latter, do we have a bug # for tracking?

• Testing: We need better automated testing in both rendering and in unit-tests. cxxtests is awkward to use (and nobody seems to look at it, there are many tests failing now).

So here we need three things:

1. Hardware somewhere to run the automated tests

2. Automated tests, and maybe a framework to run them and collect/present results

3. Regular reviewers who can sort out false positives and framework bugs from legitimate bugs, and then (quickly) escalate the problems so they get acted on.

In my experience with automated testing people seem to assume that's the order of importance, but in truth it's the reverse. People can review and act on test failures in the absence of #1 and #2, but having #1 and #2 is worthless without a strong #3. You just end up generating a LOT of data no one looks at, and someone ends up spending a lot of time maintaining the service - time that would have been better spent just fixing bugs! :-)

So, my advice when doing automated testing is to invest FIRST in #3. Once you have good processes in place for escalating test failures, and are seeing them be effectively acted on, *then* work on automating, and once you have automation solved, *then* worry about hardware.

• Patch reviews: We need to be quicker in reviewing patches or we risk losing new devolopers. We might need to revisit our very easy access to code check-in rights. A person writing Python extensions might not be as proficient with C++.

For the latter part, what I favor is, like I mentioned, establishing a contrib extension pool with a more open access, but that we don't actually distribute.

From that, individual extensions could be pulled into either a core

package (included with inkscape itself), or an extras package (which we could update asynchronously -- and more frequently -- than core inkscape).

• PDF Export: We discussed various strategies for improving our export to PDF, especially focusing on CMYK. Krzysztof has some ideas for achieving this. After our meeting, we had further discussions with people from Scribus on this topic. This topic is also coupled into possibly supporting other rendering methods (e.g. GEGL).

  There are a couple possible solutions. One is to extend Cairo to handle color profiles. This might not be so hard as we could write out RGB but include a color profile to hand RGB to CMYK conversion. One problem is that Cairo doesn't support the color-depth we would like. The second is to write our own PDF exporter. While Scibus's PDF export code is tightly coupled to the rest of Scribus, it can serve as a good model of what we need to do.

  The current "recommended" way of getting good PDF CMYK files is to pass Inkscape's SVG through Scribus. This is problematic as SVG support in Scribus is behind Inkscape's. Filters are not supported in Scribus. Adib will look in to possible filter support in Scribus.

I like the idea of extending Cairo with the required color support, as that might solve issues for people more widely. However this isn't an area I have much knowledge in. I'd be curious to understand more specifically what'd need added to Cairo so I can see how doable it'd be.

• Export: Our export mechanisms needs to be unified, probably with a "visitor's" model.

Guessing that this could be achieved via a refactoring effort?

• Filters: Needs to be reworked to follow the model of other objects. (There are hacks needed now to get the rendering done correctly.)

Would be nice to understand this in more detail. Sounds like another possible refactoring effort.

As an aside, both of these above two things sound like good material for hackfest work.

• Multipage SVG: We discussed ways to use groups (layers) to handle multipage SVGs. The layer dialog might be modified with some added Inkscape name-space attributes to have groups of layers of which selecting one will hide the others in the group. (This would make editing JessyInk presentations much easier!) Martin has volunteered to put a plan together.

A long needed feature, looking forward to seeing the plan.

• Remove need for "id" attributes. (Krzysztofv has an idea on this.)

Another refactoring project?

• Excessive signaling. Why does dragging a gradient handle cause closed dialogs to call style handling code?

Bet this will uncover some bugs and broken architecture.

• BZR migration: BZR is no longer under development.

Agreed, but we'll postpone discussion of this hot topic til post-release.

Bryce