On Thu, Jan 05, 2017 at 02:39:52PM +0000, Martin Owens wrote:
Firstly,
Three cheers for Bryce, without whom we would have no release at all.
Let me add some thoughts to your postpartum below...
Overall I think it went quite well. Switching build systems was a big change, and getting two year's worth of feature work stabilized is quite an achievement.
Yes, it's quite the achievement. Each release build is a way for us a programmers to say "Users matter and this is a thing we think users should have" and it shows the project is not just a collection of self interested coders, but also selfless volunteers that can get a lot of these tasks done even if we don't benefit in a direct way.
Releases are perhaps the most primary target for paid work, where the money comes from users. Especially given it's laborious, managerial (pointy haired boss eh bryce ;-)) and could do with more attention.
Perhaps we could have a fund raising just for the next release, we'd be setting ourselves some harder deadlines and if successful, we'd have the money to pay for say a person or two to work on bugs and management aspects.
There's a lot of things we could do if we could get stronger fundraising efforts going. Our limiting factor is (as usual) manpower.
I see tackling bugs to be a big part of the problem. We may have to have a talk about what it means to be an "Inkscape Developer" capital I, capital D. Our requirements right now are two commits to trunk ever in the past. There's no long term plan for members to retire and no bug fixing requirement to keep an active Developer status.
We don't even specify in the about screen which members were active in the last ten years of development. Anyone ever is in that list. Which is good for voting, things like the board voting should be open to all alumni. But for the kinds of attribution that is rewarding to see, we don't really pay much attention and can't offer anything to bug fixers.
Improving incentivization for doing bug fixing work is a very good idea. That and patch review are the most direct impacts on the software's quality.
Structuring membership better is an interesting thought, and potentially something worth revisiting as part of the migration to git. I'd be hesistant about adding bug fixing as an actual requirement, as that could have unintended consequences that we don't want. But an expectation that some minimum level of activity be maintained in order to retain membership status doesn't seem unreasonable; the board has requirements like that regarding voting, and the X.org foundation actually forces all members to re-register each year.
a more timely fashion. Does anyone have suggestions or observations that could help us improve this?
A service that does timed and shared task management might be an improvement. I noticed there was a lot of manual work with regard to task management.
Yes, it's a bit overwhelming how many little tasks there are in getting a release out the door. Tracking tools might help, though my hope is a lot can be automated away, or process changes can make them unnecessary. Of course, achieving both those things requires... tasks.
So yeah, there could potentially be some needs that a shared task management tool could help address. The crux of the problem is less about keeping track of the tasks themselves, but rather in locating people willing to do them. Maybe that's what we actually need here, a "contributor tracker" tool.
huge positive impact Inkscape has made in people's lives and careers, and the 0.92 release you've created is going to enable a lot of people to do some really great things.
Inkscape is one of those things in the world that provides millions of dollars worth of economic and social value but which takes very little money. Something Open Source projects can always be proud of.
But there's space to think about having our different user groups (cnc, artists, animators, web designers, tracers etc etc) involved in sorting out the major issues they have with their respective workflows. I noticed that while a laser cutter problem is critical to workshops and school use of inkscape, it was wishlist or low priority for the project as a whole. That presents us with a problem where Inkscape is great for 90% of the work, but has critical failures for 90% of workflows at the same time.
Very good points. I've also wondered about if Inkscape's GUI could be better structured along workflow lines, as a means to maybe declutter the interface and/or enable performance optimizations. For instance, freehand drawing art isn't going to care much about snapping or grids and disabling them could have rendering performance benefits. Whereas with drafting and CNC snapping can be crucial and rendering performance tends not to be so much of an issue.
Done well, this could directly address the UX complaints that are cropping up. We've squeezed in a lot of amazing functionality into Inkscape over the years, but every new button or widget adds to the overall "weight" of the UI, making the tool more powerful but also incrementing the effort needed to learn it.
Bryce