Hey Devs,
I noticed the render bug was patched, how long do we think we'll have before we do a new release?
As for the release of the staging website, I'm still planning on releasing what ever content we have in Novemeber 14th to live. I figure everyone will be happy with it by then.
It'd be nice to get a new release ready for then too, but that might be too short notice considering all the changes and probable other bugs.
Thoughts?
Martin Owens
The first thing that must be achieved is having all of the blocker bugs closed. See: https://bugs.launchpad.net/inkscape/+bugs?field.tag=blocker
In addition too that, we will need to bring a copy of cairo and pixman in-tree for a while to ensure the new renderer will work everywhere. I think that the cairo hooks for the new downsampling in pixman just landed in unstable upstream. Not exactly a great time to think about doing that imho.
We also need to do a frost, feature freeze, string freeze (to give translators some time to update translations) then the normal pre-releases for additional testing, etc.
At this time there is no foreseeable way that a new release will be ready by then unless people really step up on those blockers.
Cheers, Josh
On Mon, Sep 9, 2013 at 1:56 PM, Martin Owens <doctormo@...400...> wrote:
Hey Devs,
I noticed the render bug was patched, how long do we think we'll have before we do a new release?
As for the release of the staging website, I'm still planning on releasing what ever content we have in Novemeber 14th to live. I figure everyone will be happy with it by then.
It'd be nice to get a new release ready for then too, but that might be too short notice considering all the changes and probable other bugs.
Thoughts?
Martin Owens
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2013-09-09 at 15:46 -0700, Josh Andler wrote:
In addition too that, we will need to bring a copy of cairo and pixman in-tree for a while to ensure the new renderer will work everywhere.
So bug #804162 is solvable by bringing cairo and pixman into tree. That brings us down to 10 bugs.
Probably best to put us into a freeze, to deal with these bugs (and probably some others). Is there a reason to not plan for this kind of release process after GSoC has ended?
Martin,
Most of the blockers have got some age on them... it's not worth freezing until we're less at less than 5 and it's obvious that they're being actively worked on. I would love to see a release before the end of year holidays... but that would be the quickest wind down to a dev cycle we've had in years. Also, it would be good to know the status of packaging on OSX and if there has been any progress on 64-bit windows lib work and the msi installer that was being tested at one point.
Cheers, Josh
On Mon, Sep 9, 2013 at 4:32 PM, Martin Owens <doctormo@...400...> wrote:
On Mon, 2013-09-09 at 15:46 -0700, Josh Andler wrote:
In addition too that, we will need to bring a copy of cairo and pixman in-tree for a while to ensure the new renderer will work everywhere.
So bug #804162 is solvable by bringing cairo and pixman into tree. That brings us down to 10 bugs.
Probably best to put us into a freeze, to deal with these bugs (and probably some others). Is there a reason to not plan for this kind of release process after GSoC has ended?
Martin,
On Mon, 2013-09-09 at 16:45 -0700, Josh Andler wrote:
Most of the blockers have got some age on them... it's not worth freezing until we're less at less than 5 and it's obvious that they're being actively worked on. I would love to see a release before the end of year holidays... but that would be the quickest wind down to a dev cycle we've had in years. Also, it would be good to know the status of packaging on OSX and if there has been any progress on 64-bit windows lib work and the msi installer that was being tested at one point.
Cheers, Josh
But we should set a target date or there is no motivation to work on the bugs. (At least it helps me to get motivated!)
Some of those blockers are really, really old.... While I would love to see them all fixed, I wouldn't block on them unless they are regressions.
On Mon, Sep 9, 2013 at 4:32 PM, Martin Owens <doctormo@...400...> wrote:
On Mon, 2013-09-09 at 15:46 -0700, Josh Andler wrote:
In addition too that, we will need to bring a copy of cairo and pixman in-tree for a while to ensure the new renderer will work everywhere.
I don't really like the idea of bringing cairo and pixman into the tree. For Windows and Mac, aren't they already included somehow? For Linux, by the time of release, the distros should already be up-to-date with the latest Cairo assuming that 1.14 is released in mid-October as planned (see cairo mailing list 5 Sept).
So bug #804162 is solvable by bringing cairo and pixman into tree. That brings us down to 10 bugs.
Probably best to put us into a freeze, to deal with these bugs (and probably some others). Is there a reason to not plan for this kind of release process after GSoC has ended?
Definitely need to wait for GSoC to end... and the a little bit longer.
Tav
Because I always have to search for it: blocker list: https://bugs.launchpad.net/inkscape/+bugs?field.searchtext=&orderby=-imp...
On Tue, Sep 10, 2013 at 2:08 AM, Tavmjong Bah <tavmjong@...8...> wrote:
But we should set a target date or there is no motivation to work on the bugs. (At least it helps me to get motivated!)
Dates don't seem to motivate anyone all that much. We could have released a while back if people really wanted it. People bring this up every couple of months and these damn bugs are brought up *every time*. Something like 2 or 3 of them have been closed in a year and a half. No real movement on them. All dates will do is piss off the users who read the devel list when we're past the date and not gearing up for release.
I guess this appears to be a chicken and egg problem... but given that proposed release plans have been thrown out a couple times in the past and those bugs didn't get worked on, it's not possible to set a date until people start knocking them down. When the list is at half of what it is it would be reasonable to put a release plan into action... but in the end, the blockers will still do just that... block a release from being possible.
Some of those blockers are really, really old.... While I would love to see them all fixed, I wouldn't block on them unless they are regressions.
All but 2 are regressions (sorry, one marked as fix committed got bumped back to confirmed as Krzysztof pointed out the proper solution as opposed to a filesize increasing workaround). So we have one that increases filesize when jpegs are embedded (unless they already had the least amount of compression possible). The other one that's not a regression: https://bugs.launchpad.net/inkscape/+bug/243729 is way too old and can really screw up people's workflow (and is panic inducing) if they're unaware of it. Either way, saving and reloading the document is an incredibly irritating workaround when you just need to be productive. I hit that bug numerous times working on marketing materials for the last SCaLE and since I was unaware of the bug, I lost at least 6 hours of time that I could have been productive because I had no clue what was going on.
I don't really like the idea of bringing cairo and pixman into the tree. For Windows and Mac, aren't they already included somehow? For Linux, by the time of release, the distros should already be up-to-date with the latest Cairo assuming that 1.14 is released in mid-October as planned (see cairo mailing list 5 Sept).
The 1.12 cairo release slipped over half a year from when it was originally proposed (not blaming or ragging or anything, we're WAY overdue). The only reason I have any hope that they can make it is because Bryce is now working on cairo upstream. I HATE the idea of us bringing more libs in-tree temporarily, but in this instance, it's actually Linux users/developers that would suffer if we don't.
Unless we change our policy, we can't release without bringing them in-tree until 2017. We have a policy to be developer friendly which means when the last expiration date here passes http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Distros we no longer would need to provide those libs in-tree.
Yes, we have had developers over the years who stick to LTS or just older releases for various reasons. Even bulia used to run a rather dated distro a while back, and there's no way we can block out any developers like that. Personally, it doesn't affect me because I have the option to update whenever I like. But sometimes people are working in a corporate environment where they are required to use LTS (or equivalent)... sometimes their old hardware can't run newer releases efficiently... sometimes there's just some seriously odd issue as I seem to recall was bulia's problem.
Definitely need to wait for GSoC to end... and the a little bit longer.
Yes, a little bit longer than after GSoC... GSoC work always needs to be refined and polished, it's just the nature of the program.
Cheers, Josh
On Tue, 2013-09-10 at 07:01 -0700, Josh Andler wrote:
Dates don't seem to motivate anyone all that much. We could have released a while back if people really wanted it.
That's some cynicism Josh. We know that Inkscape's woe is not in the /want/ of people. It's possible developers have a bounty of untapped unpaid time lurking somewhere, but without more upbeat go-getting, positive "WE CAN DO THIS" rallying cries from the leadership... what are you expecting?
You, Bryce, Jazzy, Cruz or bbyak, we only need one to push a release forward from the project leadership. But we need all our leaders/administrators to be upbeat, even in the face of crushing economic reality and bad prior experiences.
All dates will do is piss off the users who read the devel list when we're past the date and not gearing up for release.
We don't have to date the actual release. We can instead date an open-ended freeze process. Pencil in a /want/ for a release, but no date of release.
Although that's harder to enforce with our trunk committing policy, it should be possible to ask feature writers to help fix bugs.
and those bugs didn't get worked on
Don't feel bad about that. That's more likely economics, not a lack of commitment. You talk like someone who's given up already, carrying millstones of previous attempts to do things. Things can still get done, but our leaders must be fearless and quite possibly blissfully ignorant of their past failures. ;-)
Hell, I haven't gotten any help putting in one file into the build system. I don't feel bad. Soon, I'm going to smash into automake like hulk until it works "HULK CHANGE AUTOMAKE MAKEFILE! BUT HULK NO CAN BUILD TARBALL!"
Unless we change our policy, we can't release without bringing them in-tree until 2017.
Change of policy it is then, what's the process?
We can improve developer's prospects on older releases by having branches, solid instructions, and/or scripting to set up the required code in the right places. Waiting for 2017 is silly.
Kind Regards, Martin Owens
On Tue, Sep 10, 2013 at 6:39 PM, Martin Owens wrote:
We don't have to date the actual release. We can instead date an open-ended freeze process. Pencil in a /want/ for a release, but no date of release.
Personally, I have mixed feelings about this.
We have reality where we don't have a ton of developers circling around the Bzr repo. And then we have reality where lack of a clear release date makes you lazy and unfocused :) So maybe a mixed approach could work indeed.
and those bugs didn't get worked on
Don't feel bad about that. That's more likely economics, not a lack of commitment.
Nope, Josh is correct. Things started slowing down way before recession's bottom and immediately after departure of key developers. So yes, it's about commitment and leadership. It was ever so.
Note that I'm not blaming anyone :)
Waiting for 2017 is silly.
Ditto.
Alexandre
On Tue, Sep 10, 2013 at 7:39 AM, Martin Owens <doctormo@...400...> wrote:
That's some cynicism Josh. We know that Inkscape's woe is not in the /want/ of people. It's possible developers have a bounty of untapped unpaid time lurking somewhere, but without more upbeat go-getting, positive "WE CAN DO THIS" rallying cries from the leadership... what are you expecting?
I've done a decade of cheerleading for the project. I've been one of the most upbeat, positive, and thankful people to support our developers. Ask Johan, ask Felipe, ask John Smith, ask Krzysztof, ask any number of people who have been around for a while. That said, it's easy to do that when people are energized and excited to work on things. Adding features is fun, fixing bugs is tedious and often a complete pain. For the past handful of releases, getting things locked down was a serious chore... that's not a blame thing, it's just how it has happened.
You, Bryce, Jazzy, Cruz or bbyak, we only need one to push a release forward from the project leadership. But we need all our leaders/administrators to be upbeat, even in the face of crushing economic reality and bad prior experiences.
Well, if the saying "Lead, follow, or get out of the way" applies here, then maybe it's time for me to just get out of the way. I have some rather major things going on in my family currently, so I definitely don't have the ability to pretend to be upbeat about this.
We don't have to date the actual release. We can instead date an open-ended freeze process. Pencil in a /want/ for a release, but no date of release.
This proposition already defeats the purpose. Dating something that is knowingly open-ended is the same as having no date if people tend to procrastinate or don't have a lot of free time.
Although that's harder to enforce with our trunk committing policy, it should be possible to ask feature writers to help fix bugs.
I completely agree. In fact, in a perfect world the feature authors would really have the time and ability to do that.
Don't feel bad about that. That's more likely economics, not a lack of commitment. You talk like someone who's given up already, carrying millstones of previous attempts to do things. Things can still get done, but our leaders must be fearless and quite possibly blissfully ignorant of their past failures. ;-)
I know it's not your intention, but I'm really starting to get the feeling that I just need to not be involved anymore. I can't ignore reality. I can't be ignorant of a past in which I was greatly invested. I definitely haven't given up, but I don't know how to be motivated about this right now if I don't see those bugs getting worked on in a gangbusters fashion. It would be much more motivating if we didn't carry blockers for so long. Perhaps we try to have a new policy for the next dev cycle where no new features can be committed to trunk if a blocker has existed for X amount of time.
Unless we change our policy, we can't release without bringing them in-tree until 2017.
Change of policy it is then, what's the process?
Propose the change to the devel list and if there is a majority consensus, we go with the will of the devs. I do want to say though, bringing a copy of cairo & pixman for a few years isn't ideal, but it doesn't require a change in policy.
We can improve developer's prospects on older releases by having branches, solid instructions, and/or scripting to set up the required code in the right places. Waiting for 2017 is silly.
It is silly and I never proposed that we do that. This is a decent alternative to bringing those libs in-tree imho... but still probably more complicated than us just maintaining copies of the libs in-tree.
Cheers, Josh
On Tue, 2013-09-10 at 08:45 -0700, Josh Andler wrote:
Adding features is fun, fixing bugs is tedious and often a complete pain.
I put some of that down to the job of seeing thousands of users enjoy the result, as apposed to the silence of fixing a critical bug.
Don't have the ability to pretend to be upbeat about this.
If you can't be genuinely upbeat about it, then it's time for a break... at least that's been my experience. Otherwise you'll tear a gear in your happy machine.
We don't have to date the actual release. We can instead date an open-ended freeze process. Pencil in a /want/ for a release, but no date of release.
This proposition already defeats the purpose. Dating something that is knowingly open-ended is the same as having no date if people tend to procrastinate or don't have a lot of free time.
I think you misunderstand. We'd have a date for lock-down and some targets for as long as it takes. But after freeze date, there'd be pressure to get bugs fixed with a view to have the release. We'd be in labour (so to speak) even if it's a really protracted labour, but while there wouldn't be a firm release date, there would be a fixed freeze date.
I know it's not your intention, but I'm really starting to get the feeling that I just need to not be involved anymore.
Unsubscribe, see how you feel for a week or two. Process any leadership change-over after that. Find your balance.
Perhaps we try to have a new policy for the next dev cycle where no new features can be committed to trunk if a blocker has existed for X amount of time.
Good idea, I wonder how flexible those smoke test scripts are for automatic merging.
Martin,
Maybe a stupid idea, but here I go :) Have you ever considered to crowd-fund bugfixing? (i.e.: getting money to pay somebody to do the work nobody else wants to do)
If money can be obtained from a crowdfunding campaign... is there any qualified person willing to do the job?
I know it's unfair to developers who already contributed for free, but as far as I know money is not the main motivation for hackers who persue the fun aspect of development (new features, challenges).
Maybe getting somebody paid to take care of the ugly stuff nobody wants to do is a fair balance and takes the stress out so regular contributors can focus on the fun stuff.
Of course, it's not as easy as it sounds: A qualified developer who knows the code enough and can meet the technical requirements is needed. And probably also a person willing to take care of the paperwork and administrative tasks. And people willing to review the patches...
Anyway, what do you think about this idea?
Gez.
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier.
El mar, 10-09-2013 a las 14:10 -0300, Guillermo Espertino (Gez) escribió:
Maybe a stupid idea, but here I go :) Have you ever considered to crowd-fund bugfixing? (i.e.: getting money to pay somebody to do the work nobody else wants to do)
If money can be obtained from a crowdfunding campaign... is there any qualified person willing to do the job?
I know it's unfair to developers who already contributed for free, but as far as I know money is not the main motivation for hackers who persue the fun aspect of development (new features, challenges).
Maybe getting somebody paid to take care of the ugly stuff nobody wants to do is a fair balance and takes the stress out so regular contributors can focus on the fun stuff.
Of course, it's not as easy as it sounds: A qualified developer who knows the code enough and can meet the technical requirements is needed. And probably also a person willing to take care of the paperwork and administrative tasks. And people willing to review the patches...
Anyway, what do you think about this idea?
Gez.
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Maybe a percent of the new feature donation, go auto to fix bugs.
Jabier.
El mar, 10-09-2013 a las 20:42 +0200, Jabiertxo Arraiza Cenoz escribió:
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier.
El mar, 10-09-2013 a las 14:10 -0300, Guillermo Espertino (Gez) escribió:
Maybe a stupid idea, but here I go :) Have you ever considered to crowd-fund bugfixing? (i.e.: getting money to pay somebody to do the work nobody else wants to do)
If money can be obtained from a crowdfunding campaign... is there any qualified person willing to do the job?
I know it's unfair to developers who already contributed for free, but as far as I know money is not the main motivation for hackers who persue the fun aspect of development (new features, challenges).
Maybe getting somebody paid to take care of the ugly stuff nobody wants to do is a fair balance and takes the stress out so regular contributors can focus on the fun stuff.
Of course, it's not as easy as it sounds: A qualified developer who knows the code enough and can meet the technical requirements is needed. And probably also a person willing to take care of the paperwork and administrative tasks. And people willing to review the patches...
Anyway, what do you think about this idea?
Gez.
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El 10/09/13 15:47, Jabiertxo Arraiza Cenoz escribió:
Maybe a percent of the new feature donation, go auto to fix bugs.
Jabier.
El mar, 10-09-2013 a las 20:42 +0200, Jabiertxo Arraiza Cenoz escribió:
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier: Paying for new features is always a problem. It could demotivate the creation of less popular features. It's also unfair, because if some developer gets paid for a new feature, why not all of them? And getting money for all the people involved in a non-commercial project is really a problem.
I proposed the idea of a crowdfunding campaign to cover the less sexy tasks because: - Those task already exist, and in some cases they block the advance of the project. - They can be a source of stress and demotivation in developers. They pile up, nobody does them, and instead of focusing on new features (which can be a more rewarding job) devs have to address demands of users ranting because X thing doesn't work. - Did I mention nobody wants to do it?
I bet that several developers wouldn't mind if somebody gets money for that, as long as sombody gets rid of those longstanding, annoying bugs.
Inkscape has a bugtracker with lots of detailed bug reports. The importance of those bugs has been more or less agreed by core developers. Some of those bugs are blocking a release. It wouldn't be difficult to come up with a list or priorities, set a price tag for different importance/complexity bugs and set a fundraising goal.
Of course, IF somebody qualified wants to do the job.
Gez
Thanks Gez for your opinion and the great explain. Its a good point of view.
The crow-fund could be great, you are thinking in a existing plataform? Whats your opinion about crowfunding at personal developer level new features to a GPL... software?
See you, Jabier.
El mar, 10-09-2013 a las 16:42 -0300, Guillermo Espertino (Gez) escribió:
El 10/09/13 15:47, Jabiertxo Arraiza Cenoz escribió:
Maybe a percent of the new feature donation, go auto to fix bugs.
Jabier.
El mar, 10-09-2013 a las 20:42 +0200, Jabiertxo Arraiza Cenoz escribió:
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier: Paying for new features is always a problem. It could demotivate the creation of less popular features. It's also unfair, because if some developer gets paid for a new feature, why not all of them? And getting money for all the people involved in a non-commercial project is really a problem.
I proposed the idea of a crowdfunding campaign to cover the less sexy tasks because:
- Those task already exist, and in some cases they block the advance of
the project.
- They can be a source of stress and demotivation in developers. They
pile up, nobody does them, and instead of focusing on new features (which can be a more rewarding job) devs have to address demands of users ranting because X thing doesn't work.
- Did I mention nobody wants to do it?
I bet that several developers wouldn't mind if somebody gets money for that, as long as sombody gets rid of those longstanding, annoying bugs.
Inkscape has a bugtracker with lots of detailed bug reports. The importance of those bugs has been more or less agreed by core developers. Some of those bugs are blocking a release. It wouldn't be difficult to come up with a list or priorities, set a price tag for different importance/complexity bugs and set a fundraising goal.
Of course, IF somebody qualified wants to do the job.
Gez
I'd be very reluctant to see cairo & pixman brought in tree. My experience with "unforking" GDL suggest that this could cause major maintenance headaches down the line. I think that something like the following approach would be a nicer solution:
== develpment/testing ==
1. Bump dependency versions in configure.ac etc to the required (unstable) versions of Cairo/pixman. Mark bugs as "Fix committed" 2. Create a devlibs branch with a suitable (unstable) Cairo/pixman versions 3. Create a dependency on a daily build of Cairo/pixman in the PPA
...it's then up to individual developers to install their own unstable development libs rather than it being our problem to keep it in trunk. Early adopters and beta testers will be able to continue using the PPA without having to compile from source (or know/understand what has changed).
== pre-release ==
4. Wait for suitable *stable* versions of Cairo/pixman to be released 5. Bump devlibs trunk versions of libraries 6. Kill the unstable devlibs fork 7. Bump PPA Build-Depends version in debian/control and drop dependency on daily Cairo builds 8. Test thoroughly
In any case, I don't think we should go ahead with the 0.49 release until all the dependencies are stable. If that means a longer wait, I'm fine with that!
AV
On 10 September 2013 21:42, Guillermo Espertino (Gez) <gespertino@...400...> wrote:
El 10/09/13 15:47, Jabiertxo Arraiza Cenoz escribió:
Maybe a percent of the new feature donation, go auto to fix bugs.
Jabier.
El mar, 10-09-2013 a las 20:42 +0200, Jabiertxo Arraiza Cenoz escribió:
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier: Paying for new features is always a problem. It could demotivate the creation of less popular features. It's also unfair, because if some developer gets paid for a new feature, why not all of them? And getting money for all the people involved in a non-commercial project is really a problem.
I proposed the idea of a crowdfunding campaign to cover the less sexy tasks because:
- Those task already exist, and in some cases they block the advance of
the project.
- They can be a source of stress and demotivation in developers. They
pile up, nobody does them, and instead of focusing on new features (which can be a more rewarding job) devs have to address demands of users ranting because X thing doesn't work.
- Did I mention nobody wants to do it?
I bet that several developers wouldn't mind if somebody gets money for that, as long as sombody gets rid of those longstanding, annoying bugs.
Inkscape has a bugtracker with lots of detailed bug reports. The importance of those bugs has been more or less agreed by core developers. Some of those bugs are blocking a release. It wouldn't be difficult to come up with a list or priorities, set a price tag for different importance/complexity bugs and set a fundraising goal.
Of course, IF somebody qualified wants to do the job.
Gez
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2013-09-10 at 16:42 -0300, Guillermo Espertino (Gez) wrote:
Paying for new features is always a problem. It could demotivate the creation of less popular features.
I've been thinking about this problem for a while now. I'm a big supporter of funding for projects; but people are right to criticise the lack of progress surrounding how to organize administratively and culturally. I still might not have gotten all the ideas out in this email.
What I've got to is: There needs to be a couple of separations implemented in order to make payments, funding, crowd sourcing work through the project rather than appended:
1) Separate investor and producer. If you're a volunteer developer; then at that instance you are both investing and producing. If you are being paid to develop then you are /just/ the producer and if you are paying then you are an investor. The investor should be a separate role in a project much like a translator, bug hunter or designer. -> Addendum: A volunteer can quite often be self-serving, charitable or dedicated to responsibility. These tones are important to the mental context for any contribution and thus the social interaction.
2) Separate gratitude from recognition. I recognize that the amazing developer 'Sarah' has committed some incredible code, but I'm grateful to Sarah's brother who funds her work on Inkscape. This allows us to think more about how we show our gratitude and how we show our respect and how those are different, maybe formulating what we currently do ad-hoc into a more coherent show of gratitude and/or respect.
3) Donations from investing. Donations are an interesting problem for Free Software because they sort of work counter to the nature of production. Software is made, then software gets small tokens of appreciation randomly... even though it's already been paid for. The best way to think of donations to the conservatory is that it's a 'appreciation fund' which acts as a single investor with it's own charter (in our case: "What's good for inkscape"). This doesn't mean that this fund is the only the money the project deals in, pipes through, organises or otherwise understands is involved in the project. What tends to happen is that this appreciation fund gets confused with appreciation payments to developers. i.e. I appreciate the work you've already done. Which it's not. See 2)
You can see how a confusion of these items produces the following social behavioral scenario:
Bob spends some time fixing bugs in Inkscape. Robert gets paid $300 from the conservatory to fix some bugs for Inkscape. Bob is jealous of Robert that his work wasn't appreciated or rewarded likewise with money. Firstly 1) Bob doesn't think he's an investor and doesn't conclude that his past investment is completed, even if he's project reputation continues to grow from it. 2) Bob confuses payment for gratitude because the project has no other way of showing gratitude and 3) Doesn't get why he shouldn't share in donations since they're for past achievement.
These are the kind of policies I would like to talk about with you all:
i Accept funding into the donation pool from multiple sources, but be hard-line that the decision about where is goes is completely distinct to it's source. ii. Authorise/back and/or organise funding to developers and other contributors through crowd funding or grants. GSoC belongs here. iii. Allow companies to solicit developers on list, but with policies surrounding how developers should operate. iv. Require developers working on behalf of an investor to use a note in the merge message crediting them. This level allows developers to both work in their free time and for someone at the same time. v. Branches and Code reviews which can separate work and allow data to feed scripts which can bring to our attention for acclaim. Trunk commits would be considered off-record unless they have a fixes/bug tag and can be tracked. We can also use the reviews to personally show how much we respect the code being written and gives a good place for it. vi. Blueprints to structure some of the work to improve planning. Make sure organised funding either via conservancy or kickstarter etc is well defined and scoped. We can always talk about the merits of funding one blueprint over another. This could even be as simple as 'fix these critical 10 bugs', but it would be the place to record that fact. vii. Weekly or monthly emails of gratitude and respect (separate sections) which can pull in information and reinforce our thanks for developers investing as well as our respect for developers contributing technical marvels. (This would include thanking Google for a couple of weeks every year, but that's ok IMO) viii. Getting users involved by sending such things to the users list as well as encouraging fan art for/about /investors/ thanking them. (if you think this is cheesy, it allows starving artists to show how much our work means to them)
What do you think?
Best Regards, Martin Owens
Time to write email: 2 hours... lots of unpaid work in this email ;-)
I have little Open Source experience, because Inkscape is the only Open Source project I've contributed to (lib2geom doesn't count). To me, assigning a more prominent role to money detracts from our project.
It would help me to have some info about: - other projects that have some funding scheme and how it works out for them - how much money are we talking about? - who feels comfortable helping out a payed bugfixer with fixing his bug? i.o.w., where do we find a bugfixer than actually *can* fix a bug, without help from volunteers?
Counter to the general opinion here, I don't believe bug fixing is unrewarding. I believe many people here are just not capable of fixing it (without some serious effort into learning new stuff), myself included.
If we start paying money for fixing some bugs, do we plan this as a one-off thing or do we really believe it is a sustainable scheme? I don't believe it is smart to pay money for explicit results piece by piece. What if the money stops for a bit? Did we just lose another dev? I have a lot less problems with money going to people that have worked on the project for a while and are "rewarded" with a payed job, compared to someone who has never worked on Inkscape and gets the same payed job.
---- Martin Owens <doctormo@...400...> wrote:
On Tue, 2013-09-10 at 16:42 -0300, Guillermo Espertino (Gez) wrote:
- Separate investor and producer. If you're a volunteer developer; then
at that instance you are both investing and producing. If you are being paid to develop then you are /just/ the producer and if you are paying then you are an investor. The investor should be a separate role in a project much like a translator, bug hunter or designer.
Crediting an investor (more than we do now) feels like a slap in the face of developers. Yes, indeed, a volunteer developer is investing in the project. But I feel this investment is much larger than simply a monetary investment. (it's just money) It'd be a shame if someone simply paying money can earn any credit at all that is even remotely comparable to what Bulia, etc. deserve. We shouldn't overdo the whole crediting thing. There is a huge range of deserved credit in our project. Fixing 10 bugs or writing a new feature should make you feel good for yourself, not because the official Inkscape team writes you an official thank you email according to procedure.
Cheers, Johan
Btw, an experimental study showed that "Reminders of money, relative to nonmoney reminders, led to reduced requests for help and reduced helpfulness toward others. Relative to participants primed with neutral concepts, participants primed with money preferred to play alone, work alone, and put more physical distance between themselves and a new acquaintance. " DOI: 10.1126/science.1132491 Simply reading this email does that to you.
On 09/11/2013 09:54 AM, jbc.engelen@...2592... wrote:
Counter to the general opinion here, I don't believe bug fixing is unrewarding. I believe many people here are just not capable of fixing it (without some serious effort into learning new stuff), myself included.
You've hit the nail on it's head IMHO! In the past I've found it much fun to fix bugs; quite often it took only one or two evenings, giving me quick fix ;-). Mostly though they were either related to snapping, or in general just low hanging fruit. The remaining blocker bugs though are not that easy to fix without a serious learning curve for that specific part of code, as far as I can tell. I'm considering though to sink my teeth into on of those blocker bugs and just see how far I can get...
Diederik
On Wed, 2013-09-11 at 09:54 +0200, jbc.engelen@...2592... wrote:
other projects that have some funding scheme and how it works out for them
Blender: http://www.blender.org/blenderorg/blender-foundation/ - 4 hired developers, works with 'entrepreneurs and companies'
The idea is not to have funding activities dominate or even be all that prominent. But having that kind of infrastructure in place supports this contribution route better.
Bugs - Spending 3 days leading about libxml2 is just as much part of the job of tedious bug fixing as the quick coup de squish.
Martin,
If we want to go the donation to fix bugs route there will need to be a majority consensus from the developers (translators and other community members don't get included in this vote as they fall into different categories). The short version of this is we really wouldn't want to upset anyone or have ill-will or tensions arise because others get compensated while their efforts do not.
If the developers did want to pursue this, we could then bring this to the attention of the board. My guess is that if we really had a large portion of the developers wanting to see this happen, the board would not likely oppose it. After that we could then discuss with Bradley Kuhn from Software Freedom Conservancy how to go about implementing this. If someone wants to try and organize a vote, feel free.
Cheers, Josh
On Tue, Sep 10, 2013 at 11:47 AM, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
Maybe a percent of the new feature donation, go auto to fix bugs.
Jabier.
El mar, 10-09-2013 a las 20:42 +0200, Jabiertxo Arraiza Cenoz escribió:
I like a lot but not only for boring task. Maybe the donating sistem need to be updated to sweet final user feature promotion. Think some GPL proyects do this.
Jabier.
El mar, 10-09-2013 a las 14:10 -0300, Guillermo Espertino (Gez) escribió:
Maybe a stupid idea, but here I go :) Have you ever considered to crowd-fund bugfixing? (i.e.: getting money to pay somebody to do the work nobody else wants to do)
If money can be obtained from a crowdfunding campaign... is there any qualified person willing to do the job?
I know it's unfair to developers who already contributed for free, but as far as I know money is not the main motivation for hackers who persue the fun aspect of development (new features, challenges).
Maybe getting somebody paid to take care of the ugly stuff nobody wants to do is a fair balance and takes the stress out so regular contributors can focus on the fun stuff.
Of course, it's not as easy as it sounds: A qualified developer who knows the code enough and can meet the technical requirements is needed. And probably also a person willing to take care of the paperwork and administrative tasks. And people willing to review the patches...
Anyway, what do you think about this idea?
Gez.
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (9)
-
unknown＠example.com -
Alex Valavanis -
Alexandre Prokoudine -
Diederik van Lierop -
Guillermo Espertino (Gez) -
Jabiertxo Arraiza Cenoz -
Josh Andler -
Martin Owens -
Tavmjong Bah