Post-Mortum: Line height bug

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Post-Mortum: Line height bug

Martin Owens-2
Developers,

As someone how changed the line-height code prior to release, I feel
somewhat responsible for the issue in 0.92. I really didn't have enough
time to focus on bugs before the release, but should have spent more
time on things I'd changed. I'm really sorry Inkscape.

This thread isn't for figuring out how we're going to solve the issue
though. I'll let the 0.91.1 discussion cover that.

What I'd like to pick apart is our bug management and how a release
blocker like this line-height issue didn't put an all stop on our
release schedule while we figured it out.

There's a couple of possibilities:

 1. The bug wasn't discovered in time
 2. The bug wasn't reported in time
 3. The reported bug wasn't triaged in time
 4. The bug wasn't prioritised as important
 5. There wasn't a way to communicate a major issue to the release
manager.
 6. We just didn't have the resources to do the release properly and
let things slide.

What information can Mc and su_v add about the issue? What can we fix
to make the process better?

I feel bad asking for your help to really figure this out, but I think
this might help us as a project overall if we know what happened and
how to defend against it.

Thanks everyone.

Best Regards, Martin Owens
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (836 bytes) Download Attachment
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

C R
While helping troubleshoot the bug before the release, I got the impression that Text handling was always a second-class feature of inkscape - it's never had the attention it needed to be considered a reliable professional tool. Advice for clunky workarounds has become how it works (jiggle it with the arrow keys so it saves properly, for example).

There was some attention paid to fixing the tool, just not enough paid to making sure old template files still work, and fixed automatically upon the next save.

All this is much easier said than done. I guess I just accepted that old templates were not going to show properly for this release, because I really appreciate the progress that has been made to making the tool more usable.

And that's what I hear from people who use inkscape for templates in the GNOME project- They are simultaneously upset that the old templates don't show correctly, but "at least the text tool is more usable now"

So I guess going forward it makes sense to assign a higher priority to the text features of inkscape as well as a backward compatibility for previous templates, to bring them up to speed with the necessary changes to the text tool, without the need for dialogs.

My 2p
-C





On 21 Jan 2017 4:57 a.m., "Martin Owens" <[hidden email]> wrote:
Developers,

As someone how changed the line-height code prior to release, I feel
somewhat responsible for the issue in 0.92. I really didn't have enough
time to focus on bugs before the release, but should have spent more
time on things I'd changed. I'm really sorry Inkscape.

This thread isn't for figuring out how we're going to solve the issue
though. I'll let the 0.91.1 discussion cover that.

What I'd like to pick apart is our bug management and how a release
blocker like this line-height issue didn't put an all stop on our
release schedule while we figured it out.

There's a couple of possibilities:

 1. The bug wasn't discovered in time
 2. The bug wasn't reported in time
 3. The reported bug wasn't triaged in time
 4. The bug wasn't prioritised as important
 5. There wasn't a way to communicate a major issue to the release
manager.
 6. We just didn't have the resources to do the release properly and
let things slide.

What information can Mc and su_v add about the issue? What can we fix
to make the process better?

I feel bad asking for your help to really figure this out, but I think
this might help us as a project overall if we know what happened and
how to defend against it.

Thanks everyone.

Best Regards, Martin Owens
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

Marc Jeanmougin
In reply to this post by Martin Owens-2
On 01/21/2017 05:55 AM, Martin Owens wrote:

> There's a couple of possibilities:
>
>  1. The bug wasn't discovered in time
>  2. The bug wasn't reported in time
>  3. The reported bug wasn't triaged in time
>  4. The bug wasn't prioritised as important
>  5. There wasn't a way to communicate a major issue to the release
> manager.
>  6. We just didn't have the resources to do the release properly and
> let things slide.
>
> What information can Mc and su_v add about the issue? What can we fix
> to make the process better?

I'd say mostly 4+6.
The bug was discovered in pre2, reported (several times) and triaged in
pre3, but classified as "Medium"[0]

Medium is "moderately serious incorrect behavior that is likely to
affect many users"[1]. The criteria for bug severity management might be
a bit too subjective, I think: is "text lines are displaced" moderately
serious ? very serious ? IMHO, anything that changes what the output of
"inkscape $file.svg -e $file.png" for any file by more than a few pixels
should be considered with "critical" priority: This means it can break
any files created in the past.

The drawback of having "millions of users" but half a dozen devs is that
the diversity of files "out there" created and managed with inkscape is
probably far ahead of what we could possibly test and shipping a version
with such a defect would feel like if there was a version of gcc that
shipped, mostly fine but changed the semantics of some of my code.[4]

What affects "many" or "most" users is also subjective: If you don't use
a feature at all (some people do not use LPE, some people do not use
texts, no one uses 3d boxes), at the same time you'll be less likely to
notice the regression, and to consider it as important. About this, I'd
favour developing automated rendering tests after the git migration. A
few files with all existing inkscape features used in them, ideally
created with a variety of old templates, and automatically running
inkscape on them when comitting + comparing to the normal rendering (I
think it might be possible with git pre-receive hooks(?)).
Wrt "blocker": [2] was proposed as a blocker (in november); and
discussed quickly at the at the board meeting of dec 02 [3].

In hindsight, it might have been better to choose "delay the release"
instead of "document the issue / start targeting it for .92.1". IIRC,
there was some time pressure with a small timeframe to launch before a
next debian or ubuntu feature freeze (Debian stretch Jan 5?), so that
may count as "we did not have the resources to do the release properly"
? We were also, at the time, quite focused on wanting to spread the mesh
functionality, fast, with as few bugs as possible, with it having only
been tested in trunk and the last RC. That we managed to sort of do it
is probably a feat, but it might have come with the cost of letting that
regression slide, considering our limited manpower.


(tldr on suggestions: every rendering change of old files treated as
critical; automating tests)

=====
[0] https://bugs.launchpad.net/inkscape/+bug/1642133
[1] https://inkscape.org/en/develop/bug-management/#Bug_importance
[2] https://bugs.launchpad.net/inkscape/+bug/1645016
===[3]===
22:54 < su_v> users of 0.92 will face trouble with (relative) line
heights in "legacy" files (due to the changes in 0.92.x to base that on
parent <text> style
22:54 < bryce> 3 weeks would give us a Christmas release, which might be
nice
22:54 < su_v> )
22:54 < bryce> otherwise we got holiday breaks and stuff, pushing us to
like 1st or 2nd week of Jan
22:55 < su_v> will this be a FAQ (as in: redo the file in 0.92.x, or
don't upgrade), or are there other options?
22:56 < Tavmjong> su_v: Can you give me some sample files that will have
problems with line heights?
22:57 < bryce> su_v, at this point the options are document the issue,
or postpone the release
22:57 < su_v> Tavmjong: I can give the steps to reproduce (it can be
observed in 0.92x itself, too)
22:57 < su_v> Tavmjong: steps after the meeting
22:58 < jabiertxof> to me this line height problem could be a blocker
https://bugs.launchpad.net/inkscape/+bug/1645016
22:58 < bryce> please no more blockers! :-)
22:59 < bryce> but 0.92.1 is certainly something we can start targeting
with some of these more serious issues
22:59 < su_v> no one will dare to declare a bug as blocker anymore
23:00 < jabiertxof> jabiertxof block his block
23:00 < Tavmjong> jabiertxof: I can have a look next week after the
mesh/dpi stuff is done.
======
[4] I don't think that comparison is exagerated : Imagemagick's
"convert" uses inkscape if found, so right now, anyone upgrading
inkscape and using convert in scripts, will have grave regressions when
automatically rendering svg that contain text, e.g. on web servers (I'm
thinking about mediawiki
here:https://www.mediawiki.org/wiki/Manual:$wgSVGConverters ). Just to
insist, if it's installed there, that update might do no less than break
every diagram,map,etc on wikipedia.


--
Marc

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

C R
It's a little frustrating reading the reviews from prominent designers
in the FOSS community. People seem to be quite upset that this was "an
official release", loudly blaming Open Source for this one bug in
Inkscape. (Are people really surprised that there are bugs in Inkscape
at this point?)

This is not to excuse the fact that line height is messed up, but
maybe something needs to be done about integrating the publicly
blogging career artists into having a look at the pre-release well
before the release actually happens, and providing useful feedback at
that point, so we don't get blamed for the collective woes of FLOSS.

I'd like to thank everyone for the hard work, and the hurry. I got
that the intent of this release was to provide new features some long
standing bug fixes, and to get mesh gradients working to try and push
them into the SVG spec before the world gives up entirely on making
SVG better.

This is an insider view, however. Maybe it's time to bring more
prominent FLOSS artists into the fold. I can help with outreach if
necessary.

-C

On Sat, Jan 21, 2017 at 10:39 AM, Marc Jeanmougin <[hidden email]> wrote:

> On 01/21/2017 05:55 AM, Martin Owens wrote:
>> There's a couple of possibilities:
>>
>>  1. The bug wasn't discovered in time
>>  2. The bug wasn't reported in time
>>  3. The reported bug wasn't triaged in time
>>  4. The bug wasn't prioritised as important
>>  5. There wasn't a way to communicate a major issue to the release
>> manager.
>>  6. We just didn't have the resources to do the release properly and
>> let things slide.
>>
>> What information can Mc and su_v add about the issue? What can we fix
>> to make the process better?
>
> I'd say mostly 4+6.
> The bug was discovered in pre2, reported (several times) and triaged in
> pre3, but classified as "Medium"[0]
>
> Medium is "moderately serious incorrect behavior that is likely to
> affect many users"[1]. The criteria for bug severity management might be
> a bit too subjective, I think: is "text lines are displaced" moderately
> serious ? very serious ? IMHO, anything that changes what the output of
> "inkscape $file.svg -e $file.png" for any file by more than a few pixels
> should be considered with "critical" priority: This means it can break
> any files created in the past.
>
> The drawback of having "millions of users" but half a dozen devs is that
> the diversity of files "out there" created and managed with inkscape is
> probably far ahead of what we could possibly test and shipping a version
> with such a defect would feel like if there was a version of gcc that
> shipped, mostly fine but changed the semantics of some of my code.[4]
>
> What affects "many" or "most" users is also subjective: If you don't use
> a feature at all (some people do not use LPE, some people do not use
> texts, no one uses 3d boxes), at the same time you'll be less likely to
> notice the regression, and to consider it as important. About this, I'd
> favour developing automated rendering tests after the git migration. A
> few files with all existing inkscape features used in them, ideally
> created with a variety of old templates, and automatically running
> inkscape on them when comitting + comparing to the normal rendering (I
> think it might be possible with git pre-receive hooks(?)).
> Wrt "blocker": [2] was proposed as a blocker (in november); and
> discussed quickly at the at the board meeting of dec 02 [3].
>
> In hindsight, it might have been better to choose "delay the release"
> instead of "document the issue / start targeting it for .92.1". IIRC,
> there was some time pressure with a small timeframe to launch before a
> next debian or ubuntu feature freeze (Debian stretch Jan 5?), so that
> may count as "we did not have the resources to do the release properly"
> ? We were also, at the time, quite focused on wanting to spread the mesh
> functionality, fast, with as few bugs as possible, with it having only
> been tested in trunk and the last RC. That we managed to sort of do it
> is probably a feat, but it might have come with the cost of letting that
> regression slide, considering our limited manpower.
>
>
> (tldr on suggestions: every rendering change of old files treated as
> critical; automating tests)
>
> =====
> [0] https://bugs.launchpad.net/inkscape/+bug/1642133
> [1] https://inkscape.org/en/develop/bug-management/#Bug_importance
> [2] https://bugs.launchpad.net/inkscape/+bug/1645016
> ===[3]===
> 22:54 < su_v> users of 0.92 will face trouble with (relative) line
> heights in "legacy" files (due to the changes in 0.92.x to base that on
> parent <text> style
> 22:54 < bryce> 3 weeks would give us a Christmas release, which might be
> nice
> 22:54 < su_v> )
> 22:54 < bryce> otherwise we got holiday breaks and stuff, pushing us to
> like 1st or 2nd week of Jan
> 22:55 < su_v> will this be a FAQ (as in: redo the file in 0.92.x, or
> don't upgrade), or are there other options?
> 22:56 < Tavmjong> su_v: Can you give me some sample files that will have
> problems with line heights?
> 22:57 < bryce> su_v, at this point the options are document the issue,
> or postpone the release
> 22:57 < su_v> Tavmjong: I can give the steps to reproduce (it can be
> observed in 0.92x itself, too)
> 22:57 < su_v> Tavmjong: steps after the meeting
> 22:58 < jabiertxof> to me this line height problem could be a blocker
> https://bugs.launchpad.net/inkscape/+bug/1645016
> 22:58 < bryce> please no more blockers! :-)
> 22:59 < bryce> but 0.92.1 is certainly something we can start targeting
> with some of these more serious issues
> 22:59 < su_v> no one will dare to declare a bug as blocker anymore
> 23:00 < jabiertxof> jabiertxof block his block
> 23:00 < Tavmjong> jabiertxof: I can have a look next week after the
> mesh/dpi stuff is done.
> ======
> [4] I don't think that comparison is exagerated : Imagemagick's
> "convert" uses inkscape if found, so right now, anyone upgrading
> inkscape and using convert in scripts, will have grave regressions when
> automatically rendering svg that contain text, e.g. on web servers (I'm
> thinking about mediawiki
> here:https://www.mediawiki.org/wiki/Manual:$wgSVGConverters ). Just to
> insist, if it's installed there, that update might do no less than break
> every diagram,map,etc on wikipedia.
>
>
> --
> Marc
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

Miguel Lopez
In reply to this post by Marc Jeanmougin
For this part, I think what can be considered to improve on
classification on degree of importance is maybe some way to collect data
on frequency of tools, and user-surveys on how important is a tool is or
a set of tool is, and even compatibility with earlier inkscape programs
is to be considered. That will reduce the amount of subjectivity, but
you can't eliminate the subjective factor.


On 1/21/2017 5:39 AM, Marc Jeanmougin wrote:

> What affects "many" or "most" users is also subjective: If you don't use
> a feature at all (some people do not use LPE, some people do not use
> texts, no one uses 3d boxes), at the same time you'll be less likely to
> notice the regression, and to consider it as important. About this, I'd
> favour developing automated rendering tests after the git migration. A
> few files with all existing inkscape features used in them, ideally
> created with a variety of old templates, and automatically running
> inkscape on them when comitting + comparing to the normal rendering (I
> think it might be possible with git pre-receive hooks(?)).
> Wrt "blocker": [2] was proposed as a blocker (in november); and
> discussed quickly at the at the board meeting of dec 02 [3]
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Martin Owens-2
In reply to this post by C R
Thanks CR,

I'm a little disappointed too by the reaction too. But to be honest we
provide no real road for users to drive in to help, so they've come to
expect this throw-it-over-the-wall and see what goodies were made this
time behaviour.

I do think our disconnect between the user community and developers is
biting us, and not just how users show us problems, but also how users
help provide us those resources we desperately need to spend a bit more
time on issues.

> This is an insider view, however. Maybe it's time to bring more
> prominent FLOSS artists into the fold. I can help with outreach if
> necessary.

Outreach, maybe a bit on energy too. As Mc says, half a dozen isn't
enough people to really have the energy to take care of different non-
coding tasks.

What would you do CR?

Best Regards, Martin Owens
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (836 bytes) Download Attachment
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

C R
Hi Martin,

> I'm a little disappointed too by the reaction too. But to be honest we
> provide no real road for users to drive in to help, so they've come to
> expect this throw-it-over-the-wall and see what goodies were made this
> time behaviour.

We do have pre-release versions of Inkscape compiled and ready to test
before the release. This is a time when users can peek over the wall,
and have a say in what gets tossed over. This should ideally happen at
least a month before the release is scheduled, to give professional
artists time to test in their production work and feed back to us bugs
that should be given priority, or listed as blockers. We can avoid the
tremendous bad press in this way, and the soul-crushing reviews that
go along with it.

When bugs are listed as blockers, there's usually some debate about
whether inkscape's users will find it important enough to block the
release of all the goodies that are put in. This should not be a
question. If we do not know who our user base is, and what they
require from a professional graphics program like Inkscape, we have no
hope of delivering what they need. We need more pro artists to test
and feed back.

We can start with the people who gave us bad reviews. There are some
very well known artists in the FLOSS community, who (like me) pride
themselves on using FLOSS in their workflow. They blog about it, they
post tutorials, they create massive archives full of stuff done in
Inkscape, which not only helps people learn and make art for free, it
spreads the awareness and use of Inkscape to present and future
generations of graphics people. These are our greatest allies, and
they can often be our harshest critics as well. They use Inkscape *all
the time*. It's vital that they test for us, and most of them will
probably be happy to do so, because it involves improving their
toolset as a designer.

If it's desired, I can begin networking with some of them. Let them
know that we do want and need their input for future releases. I can
also inform them when the newest pre-release is ready for testing.
What can I do? Well, I can try to get our pre-releases into as many
professional hands as possible before the release.

It's not like we didn't know about this bug - we did. It's more that
it wasn't considered a priority. This is because we do not know our
user base well enough to know if it was going to be widely considered
a catastrophy. I had mentioned before that this would break many of my
previous templates, but I was willing to accept the breakage for a
better less buggy text tool. It should not have been an either or
decision, but it was just me speaking up about it, and I didn't feel I
had the clout to proclaim that "most users" would be affected by it,
or indeed even care. Saying that today... is just me saying things. We
need to KNOW what our pro users want, not guess. To do that, we need
to get to know them, and encourage them to lend their own voices to
the conversation.

We also must adopt a friendly attitude towards users, even when they
are being unpleasant, or unhelpful. The words "patches welcome" should
never *ever* be uttered at a user unless they are offering to
contribute code. The bad press is not worth it. It's better to be
silent than to present an unfriendly face. If someone's angry, they
need to be talked down from the anger first, or left alone until the
anger subsides. Only then can we grow our helpful userbase. The nicer
we are to them, the more they will want to help. It's useful to keep
in mind that we all want the same thing: a better Professional
graphics tool for everyone.

That said, Inkscape is currently one of the friendliest projects out
there, which is what got me to stick around and it's the project I
contribute the most to as a result. I want that for other hard-core
Inkscape users too.

> I do think our disconnect between the user community and developers is
> biting us, and not just how users show us problems, but also how users
> help provide us those resources we desperately need to spend a bit more
> time on issues.

Knowing our users will help us prioritise. We don't need every user of
inkscape to contribute, but the users who use Inkscape daily for their
paid work (not just as a hobby) are going to be able to help more. We
also need more work on fixing what's currently wrong with Inkscape
before we dive into more new features.
With everything that has recently gone into Inkscape, it's somewhat of
a miracle there aren't more problems than we presently have. There's
no way, in the middle of all these changes (gtk+ and others) that I
would have thought a release was even possible. People have been
busting their butts to get everything ready with very little time and
a lot of stress to get what we have.

Everyone who contributed to this release deserves high applause for
all the work. The difference between public applause and biting
criticism is getting the release into a state where the professional
graphics community can continue cranking out tons of useful graphics
knowing that Inkscape is the same solid production tool they spend
time promoting, and especially that all the work they put into making
art for distribution and editing with Inkscape will still be usable in
versions to come.

In the mean time, the whole team has my personal thanks and
encouragement. I will try to get others on board to help.

More soon.
-C

>
>> This is an insider view, however. Maybe it's time to bring more
>> prominent FLOSS artists into the fold. I can help with outreach if
>> necessary.
>
> Outreach, maybe a bit on energy too. As Mc says, half a dozen isn't
> enough people to really have the energy to take care of different non-
> coding tasks.
>
> What would you do CR?
>
> Best Regards, Martin Owens

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Martin Owens-2
On Sat, 2017-01-21 at 19:08 +0000, C R wrote:
> In the mean time, the whole team has my personal thanks and
> encouragement. I will try to get others on board to help.

An Inkscape Professional's group?

Let me know if you manage to set up a stable community space for it. I
wish we could provide some space for this type of community.

Thanks CR,

Best Regards, Martin Owens

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Terry Brown-2
In reply to this post by C R
On Sat, 21 Jan 2017 19:08:42 +0000
C R <[hidden email]> wrote:

> We do have pre-release versions of Inkscape compiled and ready to test
> before the release. This is a time when users can peek over the wall,
> and have a say in what gets tossed over.

How do users know about these?  I lurk on inkscape-devel and
inkscape-user, so that's how I know.

Should Inkscape check for updates and show pop-ups like some other apps?

"New update is available"

and

"
New beta is available

It would really help Inkscape if you'd test it
"

realizing that that requires more code itself, an HTTP GET to find
new updates, then the pop-up and instructions on how to proceed
(probably just a hyperlink in the pop-up to the appropriate page on the
Inkscape website).

Cheers -Terry


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Maren Hachmann
Am 21.01.2017 um 23:56 schrieb Terry Brown:
> On Sat, 21 Jan 2017 19:08:42 +0000
> C R <[hidden email]> wrote:
>
>> We do have pre-release versions of Inkscape compiled and ready to test
>> before the release. This is a time when users can peek over the wall,
>> and have a say in what gets tossed over.
>
> How do users know about these?  I lurk on inkscape-devel and
> inkscape-user, so that's how I know.

- Currently: via website news, and theoretically via social media, but
this is often neglected (and possibly via news articles on software
websites - for one of the pre-releases (pre3 or pre4?), I've actually
contacted a news site, and it got posted - but as we got to pre5, I
thought they might not find that too interesting any more, the numbers
got a bit high for betas).

> Should Inkscape check for updates and show pop-ups like some other apps?
>
> "New update is available"
>
> and
>
> "
> New beta is available
>
> It would really help Inkscape if you'd test it
> "
>
> realizing that that requires more code itself, an HTTP GET to find
> new updates, then the pop-up and instructions on how to proceed
> (probably just a hyperlink in the pop-up to the appropriate page on the
> Inkscape website).
>
> Cheers -Terry

- A similar idea has been around for long (including all kinds of news
about the project + asking for donations, too), but up to now I don't
think anyone has started to implement it.

Regards,
 Maren

>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Bryce Harrington-3
In reply to this post by C R
On Sat, Jan 21, 2017 at 07:08:42PM +0000, C R wrote:
> We also must adopt a friendly attitude towards users, even when they
> are being unpleasant, or unhelpful. The words "patches welcome" should
> never *ever* be uttered at a user unless they are offering to
> contribute code. The bad press is not worth it.

This seems...  odd...  It raises a red flag in the back of my head.

Apologies that what follows is going to be a bit of a dissertation, one
the old timers will probably recognize.  It's purely philosophical so if
this sounds familiar feel free to skip to the end where the actual point
is.


In my thermodynamics courses in engineering college, we were drilled
into thinking of any process as a flow.  You draw a bubble around the
thingee you're going to study, then examine the inputs and outputs
crossing the bubble's boundaries.  If work goes in, you need to account
for heat coming out, else your thingee explodes causing mass death or
whatever.

This thinking applies broadly to a lot of other fields too.  Basically
it's just accounting work, making sure income and costs are in the
balance you need.

In traditional proprietary software, rather than heat or work, your
flowing substance is money.  End users provide a source of money, that
flows to the business owners, who pay the salaries of programmers to
introduce bugs and later take them out, and the programmers use the
money to buy games where they can make pretend explosions causing mass
death.  I won't go as far as to say money is a principle motivating
force for programmers, as it might be for say a stock broker or a car
salesman, but it is the grease that enables the whole machine to work.
The development costs have to be covered by the income from consumers,
so the process inherently needs to meet user needs, else the company
goes out of business.

With volunteer driven projects that provide products or services at no
cost to end users, the flowing substance is not money.  In volunteer
driven products money is more of a specialized tool for certain
problems, not what causes the project to actually run.  In volunteer
software projects like Inkscape, the flowing commodity is _patches_.
Like money, patches have value - it takes labor to create them, and even
though they're just intangible bits and bytes they produce changes that
have tangible value for users of the software.  Patches can be applied,
committed, tested, reverted, listed in release notes...  Having your
name as author of a popular patch can earn you attention and praise;
having your name on many good patches can earn respect and esteem;
achieving a particularly challenging patch can advance your learning and
perhaps open career opportunities you wouldn't otherwise have; creating
a perfect patch to solve a problem you care about can give you pride in
your work and self-fulfilment.  In a vibrant open source project,
patches in various states are flowing all over the place enabling
actions of all sorts to be done, and providing a whole variety of
rewards to everyone involved.  If the patch flow stops, the project dies
just as surely as the software company with no money.

However, there's a major flaw in this.  One you see hobbling a lot of
open source efforts.  This patch flow is great and all for making open
source projects work, but there is no effective role in it for end
users.  Since the software is given away for free, they don't even have
the consumer role that they would in the proprietary model.  Yes, there
is value to be gained in the respect earned from developing a product
that is widely used, in seeing fleeting but genuine expressions of
appreciation, yet that's more than offset by the inevitable (and "soul
crushing") complaints; regardless, the praise is an intangible, not a
flow commodity - goodwill doesn't fix bugs.  This situation is
extraordinarily ironic: the whole point of FOSS is to be open to users
participating in and steering projects to better meet their needs, yet
since users aren't part of the core value flow process, they effectively
have *less* influence or control.

It's even worse than that though.  Most FOSS projects - like Inkscape -
accept bug reports, feature requests, platform-specific packaging, and
so forth from end users.  A good analysis of a problem can actually be a
form of useful contribution, however the vast bulk of these tickets are
not near to that level, and are effectively just work requests -
i.e. costs.

A lot of open source projects look at this as just the price of the
model - users gain something of value for free, but only gain a say in
the process flow if they are actively participating.

So, there are two obvious approaches to this problem.  First would be to
encourage non-contributing users to become contributors and participate
in the process.  (And as a corollary ensure that new contributors are
welcomed and feel a sense of empowerment to participate in decision
making in relation to the patch flow).  The second approach would be to
expand the model to provide other more convenient ways for users to
have influence on the project.

I can see how "patches welcome" can be an irritating thing to be told.
I guess it'd be like complaining to the volunteer librarian that a book
you want is unavailable, and them saying "if you want it, feel free to
come shelve this pile of turned-in books."  You'd feel like a heel for
making demands of a volunteer, yet also feel like he was being an
asshole saying that when he could so easily just reach behind him and
find your book for you.  C R has a good point that the librarian
probably *could* get your help volunteering a bit, if they approached
you the right way, in a friendly and constructive manner.  That would be
an example of approach #1.  Approach #2 would be something like a
donation jar or a place to drop off used books for the library's book
sale.


For Inkscape, I feel it is imperative to work on both approaches, and
along with that we need to improve our internal patch flow - both volume
and quality.

So, #1 we need to welcome participation and stimulate more
contributions.  We need to encourage users to take that first step to
participate in the project, and to encourage drive-by contributors to
stick around.  There's a lot of techniques, but keeping the community
friendly and welcoming, as C R suggests, has been very effective for us
in the past.

I think it is also important to emphasize that producing Inkscape
requires much more than just code.  There are critical tasks vital if we
are to be successful at all, which have nothing to do with coding -
testing, evangelism, writing good documentation, translation,
infrastructure maintenance, website designing, user relations...  Any
one of these can become an Achille's Heel for the project if not tended
to, they're all important for moving our project forward and in my book
anyone doing any tasks in those roles should be considered an official
Inkscape developer.

Longer term is the #2 approach of expanding the model and creating novel
ways for users to influence the project.  This is where the funded
projects system fits in; it opens a new avenue for users to influence
us, by providing a mechanism for transmuting monetary donations into
patches.  And coupling it with specific development objectives, rather
than being a generic tip jar, serves the purpose of providing users some
control and influence within the patch flow, without needing to actually
write code.

Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

Eduard Braun
In reply to this post by Marc Jeanmougin
Am 21.01.2017 um 11:39 schrieb Marc Jeanmougin:
> What affects "many" or "most" users is also subjective: If you don't use
> a feature at all (some people do not use LPE, some people do not use
> texts, no one uses 3d boxes), at the same time you'll be less likely to
> notice the regression, and to consider it as important. About this, I'd
> favour developing automated rendering tests after the git migration. A
> few files with all existing inkscape features used in them, ideally
> created with a variety of old templates, and automatically running
> inkscape on them when comitting + comparing to the normal rendering (I
> think it might be possible with git pre-receive hooks(?)).

I fully agree! Proper rendering tests is something Inkscape lacks the most.
While working on Scour (which is really tiny compared to Inkscape) I
learned proper tests are a lifesaver! Even tiny changes often break
things one would have never thought of. By adding at least one test for
every new feature and every bug fixed one can almost be sure that a
change which does not break tests is save to commit.

This will be especially helpful for Inkscape as we're a very "friendly"
community as mentioned before (I'd rephrase "friendly" a bit: As a
developer you're basically free to do whatever you want no matter the
consequences).
While this works OK in most cases and motivates many great new features
it is also the source of Inkscape's Achilles' heel: Regressions.

I'd very much like if we could introduce feature branches with the move
to git: People work on their own branch and push changes exclusively to
this branch. As soon as they think their changes are fit for inclusion
into the Inkscape code base they create a pull request on which
automated tests are run. As soon as those tests pass the PR can be merged.
This achieves two things: 1) Developers get a direct feedback if their
change breaks anything. Right now one can only do some manual check,
commit, and hope for the best. 2) If a feature breaks anything,
developers are still around and motivated to fix those issues to get
their new functionality into Inkscape. This prevents also situations
where a feature is added, has serious regressions and is therefore
reverted at some point, but at that time the original author of those
changes is not around any more / does not have time any more and the
feature is lost.

Regards,
Eduard

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

Bryce Harrington-3
In reply to this post by Martin Owens-2
On Fri, Jan 20, 2017 at 11:55:30PM -0500, Martin Owens wrote:
> Developers,
>
> As someone how changed the line-height code prior to release, I feel
> somewhat responsible for the issue in 0.92. I really didn't have enough
> time to focus on bugs before the release, but should have spent more
> time on things I'd changed. I'm really sorry Inkscape.

It is inspiring to see and read honesty and responsibility, there's not
enough of that in this world!

Take heart though, that the accountability here is a shared one.  We
consciously proceeded with the release knowing that there were
imperfections, including fairly severe ones.  Indeed, we were talking
about and planning for 0.92.1 *because* we knew there was more to be
done.

*I* think we did a great job.  We had an intense number of severe
problems that would likely have been far bigger impacts than this one,
which we were able to resolve.  Right now today, untold numbers of
people are using the many new features packed into this release.

I haven't seen the negative articles that folks are mentioning, but I'm
not at all surprised at mixed feedback, it was inevitable.  We live in a
society that relishes and incentivizes vocal negativity.  For one thing,
it's human nature to look at a list of good things and spot the one bad
thing and obsess over it.  Couple that with an Internet that amplifies
and a social media that works like an echo chamber.  Our media has been
well honed to focus on (and create) controversy and drama.

Given the piles of bug reports we have, if it wasn't this particular bug
it would have been one of the others.  Or a *still* missing feature.  Or
performance under some circumstance, or UX that's utterly broken for
some special use case.

Not that I think we should simply ignore complaints, or that problems
don't matter, but instead to just realize that releasing Inkscape is a
full contact sport, and we have to take the hits in order to get the
ball to the end zone.  I really want people to understand what we're
doing is not a single isolated release but a series of releases that
(hopefully) get better as we go.

Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Brynn
In reply to this post by Maren Hachmann
>>> before the release. This is a time when users can peek over the wall,
>>> and have a say in what gets tossed over.
>>
>> How do users know about these?  I lurk on inkscape-devel and
>> inkscape-user, so that's how I know.

> - Currently: via website news, and theoretically via social media, but
this is often neglected (and possibly via news articles on software
websites - for one of the pre-releases (pre3 or pre4?), I've actually
contacted a news site, and it got posted - but as we got to pre5, I
thought they might not find that too interesting any more, the numbers
got a bit high for betas).

And I've been trying to post in forums, and Maren helps with that too.  Lazur
some too, from IRC (pretty soon, we'll have him convinced to subscribe to the
lists).

It's been my opinion for as long as I've become involved with Inkscape, that
there's more of a divide between users and developers, than perhaps developers
want to admit.  As I recently explained to someone, where the mailing lists and
where irc are concerned, there isn't as much of a division.  But in forums, the
separation is shameful, in my opinion (think, Grand Canyon).

With a little guidance from developers, we could make those posts (about
pre-releases and the need for professionals and other users to test) more
prominent, and appear more important (than they do now).  As it is now, these
posts are practically just footnotes- sometimes just a single message.  When we
have the official forum, where we'll have more admin control, we can do much
more.  But even now, we should be able to make the posts appear much more
important.

What would we need from developers?  Something like how Tav explained about the
gradient mesh needing testing, and including any related wiki pages and bug
reports.  Maren took that info and made great post, and that thread got a lot
more attention than any of the other pre-release posts got.

Besides just notification about a pre-release, and where to get it, we would
need to know which tools the developers specifically would like to be tested.
Also where would they like us to report problems?  (All the while I was posting
bug reports on the gradient mesh tool, later I learned that there was a wiki
page for bug reports (??).

Maybe there should be something like a notifications team, or similar?  Release
and other community-wide info would be given to the team, and each team member
would post in their particular area (forums, facebook, twitter, IRC, website
News, bloggers, etc.).

All best,
brynn


-----Original Message-----
From: Maren Hachmann
Sent: Saturday, January 21, 2017 4:17 PM
To: [hidden email]
Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line height bug

Am 21.01.2017 um 23:56 schrieb Terry Brown:
> On Sat, 21 Jan 2017 19:08:42 +0000
> C R <[hidden email]> wrote:
>
>> We do have pre-release versions of Inkscape compiled and ready to test
>> before the release. This is a time when users can peek over the wall,
>> and have a say in what gets tossed over.
>
> How do users know about these?  I lurk on inkscape-devel and
> inkscape-user, so that's how I know.

- Currently: via website news, and theoretically via social media, but
this is often neglected (and possibly via news articles on software
websites - for one of the pre-releases (pre3 or pre4?), I've actually
contacted a news site, and it got posted - but as we got to pre5, I
thought they might not find that too interesting any more, the numbers
got a bit high for betas).

> Should Inkscape check for updates and show pop-ups like some other apps?
>
> "New update is available"
>
> and
>
> "
> New beta is available
>
> It would really help Inkscape if you'd test it
> "
>
> realizing that that requires more code itself, an HTTP GET to find
> new updates, then the pop-up and instructions on how to proceed
> (probably just a hyperlink in the pop-up to the appropriate page on the
> Inkscape website).
>
> Cheers -Terry

- A similar idea has been around for long (including all kinds of news
about the project + asking for donations, too), but up to now I don't
think anyone has started to implement it.

Regards,
Maren

>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

C R
In reply to this post by Bryce Harrington-3
Apologies. The intent of my "never say 'patches welcome' to a user unless they said they want to contribute code" is not to suggest that we should not encourage new users to contribute. I'm saying that's is not an effective way to encourage contribution. If conveying problems to the mechanic who fixes your car, and they tell you "well, fix it yourself", that does not encourage anyone to become a mechanic. It encourages them to go elsewhere.

"Patches welcome" has become a flippant and dismissive way to say, "well, fix it yourself". It's not something normal users can do without a great deal of work, and learning to code is not easy. If we want to encourage non-coding users to code, in order to fix problems in Inkscape, there are better ways to do that than just saying "patches welcome" in response to their reports. That's all I'm saying. :)
(Sorry for the double reply)
-C

On 22 Jan 2017 12:46 a.m., "Bryce Harrington" <[hidden email]> wrote:
On Sat, Jan 21, 2017 at 07:08:42PM +0000, C R wrote:
> We also must adopt a friendly attitude towards users, even when they
> are being unpleasant, or unhelpful. The words "patches welcome" should
> never *ever* be uttered at a user unless they are offering to
> contribute code. The bad press is not worth it.

This seems...  odd...  It raises a red flag in the back of my head.

Apologies that what follows is going to be a bit of a dissertation, one
the old timers will probably recognize.  It's purely philosophical so if
this sounds familiar feel free to skip to the end where the actual point
is.


In my thermodynamics courses in engineering college, we were drilled
into thinking of any process as a flow.  You draw a bubble around the
thingee you're going to study, then examine the inputs and outputs
crossing the bubble's boundaries.  If work goes in, you need to account
for heat coming out, else your thingee explodes causing mass death or
whatever.

This thinking applies broadly to a lot of other fields too.  Basically
it's just accounting work, making sure income and costs are in the
balance you need.

In traditional proprietary software, rather than heat or work, your
flowing substance is money.  End users provide a source of money, that
flows to the business owners, who pay the salaries of programmers to
introduce bugs and later take them out, and the programmers use the
money to buy games where they can make pretend explosions causing mass
death.  I won't go as far as to say money is a principle motivating
force for programmers, as it might be for say a stock broker or a car
salesman, but it is the grease that enables the whole machine to work.
The development costs have to be covered by the income from consumers,
so the process inherently needs to meet user needs, else the company
goes out of business.

With volunteer driven projects that provide products or services at no
cost to end users, the flowing substance is not money.  In volunteer
driven products money is more of a specialized tool for certain
problems, not what causes the project to actually run.  In volunteer
software projects like Inkscape, the flowing commodity is _patches_.
Like money, patches have value - it takes labor to create them, and even
though they're just intangible bits and bytes they produce changes that
have tangible value for users of the software.  Patches can be applied,
committed, tested, reverted, listed in release notes...  Having your
name as author of a popular patch can earn you attention and praise;
having your name on many good patches can earn respect and esteem;
achieving a particularly challenging patch can advance your learning and
perhaps open career opportunities you wouldn't otherwise have; creating
a perfect patch to solve a problem you care about can give you pride in
your work and self-fulfilment.  In a vibrant open source project,
patches in various states are flowing all over the place enabling
actions of all sorts to be done, and providing a whole variety of
rewards to everyone involved.  If the patch flow stops, the project dies
just as surely as the software company with no money.

However, there's a major flaw in this.  One you see hobbling a lot of
open source efforts.  This patch flow is great and all for making open
source projects work, but there is no effective role in it for end
users.  Since the software is given away for free, they don't even have
the consumer role that they would in the proprietary model.  Yes, there
is value to be gained in the respect earned from developing a product
that is widely used, in seeing fleeting but genuine expressions of
appreciation, yet that's more than offset by the inevitable (and "soul
crushing") complaints; regardless, the praise is an intangible, not a
flow commodity - goodwill doesn't fix bugs.  This situation is
extraordinarily ironic: the whole point of FOSS is to be open to users
participating in and steering projects to better meet their needs, yet
since users aren't part of the core value flow process, they effectively
have *less* influence or control.

It's even worse than that though.  Most FOSS projects - like Inkscape -
accept bug reports, feature requests, platform-specific packaging, and
so forth from end users.  A good analysis of a problem can actually be a
form of useful contribution, however the vast bulk of these tickets are
not near to that level, and are effectively just work requests -
i.e. costs.

A lot of open source projects look at this as just the price of the
model - users gain something of value for free, but only gain a say in
the process flow if they are actively participating.

So, there are two obvious approaches to this problem.  First would be to
encourage non-contributing users to become contributors and participate
in the process.  (And as a corollary ensure that new contributors are
welcomed and feel a sense of empowerment to participate in decision
making in relation to the patch flow).  The second approach would be to
expand the model to provide other more convenient ways for users to
have influence on the project.

I can see how "patches welcome" can be an irritating thing to be told.
I guess it'd be like complaining to the volunteer librarian that a book
you want is unavailable, and them saying "if you want it, feel free to
come shelve this pile of turned-in books."  You'd feel like a heel for
making demands of a volunteer, yet also feel like he was being an
asshole saying that when he could so easily just reach behind him and
find your book for you.  C R has a good point that the librarian
probably *could* get your help volunteering a bit, if they approached
you the right way, in a friendly and constructive manner.  That would be
an example of approach #1.  Approach #2 would be something like a
donation jar or a place to drop off used books for the library's book
sale.


For Inkscape, I feel it is imperative to work on both approaches, and
along with that we need to improve our internal patch flow - both volume
and quality.

So, #1 we need to welcome participation and stimulate more
contributions.  We need to encourage users to take that first step to
participate in the project, and to encourage drive-by contributors to
stick around.  There's a lot of techniques, but keeping the community
friendly and welcoming, as C R suggests, has been very effective for us
in the past.

I think it is also important to emphasize that producing Inkscape
requires much more than just code.  There are critical tasks vital if we
are to be successful at all, which have nothing to do with coding -
testing, evangelism, writing good documentation, translation,
infrastructure maintenance, website designing, user relations...  Any
one of these can become an Achille's Heel for the project if not tended
to, they're all important for moving our project forward and in my book
anyone doing any tasks in those roles should be considered an official
Inkscape developer.

Longer term is the #2 approach of expanding the model and creating novel
ways for users to influence the project.  This is where the funded
projects system fits in; it opens a new avenue for users to influence
us, by providing a mechanism for transmuting monetary donations into
patches.  And coupling it with specific development objectives, rather
than being a generic tip jar, serves the purpose of providing users some
control and influence within the patch flow, without needing to actually
write code.

Bryce

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Post-Mortum: Line height bug

Martin Owens-2
In reply to this post by Bryce Harrington-3
On Sat, 2017-01-21 at 21:04 -0800, Bryce Harrington wrote:
> *I* think we did a great job.  We had an intense number of severe
> problems that would likely have been far bigger impacts than this
> one,
> which we were able to resolve.  Right now today, untold numbers of
> people are using the many new features packed into this release.

You're right of course. And your eloquent post about user involvement
was very much on the money (you said what I wanted to say but much
better)

> Given the piles of bug reports we have, if it wasn't this particular
> bug it would have been one of the others.  Or a *still* missing
> feature.  Or performance under some circumstance, or UX that's
> utterly broken for some special use case.

In this case we may have mis-weighed the issue. considering how often
Inkscape is used to add text to a project (rather foolishly perhaps
considering svg's text support) but I'm not sure. Maybe we've taken too
much power out of the hands of the bug managers (and maybe we could do
with more bug people?) so they feel empowered to say "No, this must be
fixed before release".

> isolated release but a series of releases that (hopefully) get better
as we go.

the next release is going to rock :-D

Best Regards, Martin Owens

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line heightbug

Brynn
In reply to this post by C R
> "Patches welcome" has become a flippant and dismissive way to say, "well, fix
> it yourself".

Most of my experience helping Inkscape users is in forums (approx 8 years), as
opposed to the mailing list (approx 2 or 3 years).  I've never seen this
suggested in a flippant or dismissive way.  Even for people who come on strong
or maybe even are rantish about their complaint, we try to give them all the
info we have to address their specific issues (including manual references and
links to relevant bug reports and  website and wiki pages).

If they continue with their complaints, we remind them that Inkscape being open
source, is being developed almost entirely by volunteers, who have families and
day-jobs, and offline lives, in their spare time.  We give them info about what
open source means, in case they don't already know, and explain that development
is different than it is for proprietary programs.  Recently it's been nice to be
able to suggest funded development, since Bryce put together all that info.

Then if they still are persistent in complaining, finally, we ask if they have
any programming skills and might have some time and energy to create or fix
whatever the issue is, and including links to development parts of the website.

I know that often we are tired of hearing the same complaints over and over, and
it's all the more frustrating to give the same answers that we have so many
times before.  And we might be wishing we could easily dismiss them.  But I've
never seen anyone actually say what they are thinking.

Or I don't know, maybe it happens in mailing list threads that I don't read?  I
don't often participate on IRC, so maybe that's where this has happened?  It
seems like IRC has fast moving discussions, where people don't seem to have time
for well-thought, detailed responses.  If that's the case, we should probably
try to find some other way to offer the user an opportunity to become more
involved.

I could see a webpage....or a section of a webpage, which has kind of a pitch or
invitation.  Without looking, I don't remember specifics, but I think parts of
the faq (user faq on the website) already do this.  So it could be made into a
page or section of a page.  Since people have all different kind of issues, we
couldn't provide the support info.  But it could include generalized support
info, along with everything else I mentioned above.  And then when we find
ourselves thinking "patches welcome", we could link to it, rather than type it
all out, every time.

Or would that be too impersonal?  If the Inkscape project is known for being a
friendly community (as someone said earlier) it could be written in sort of a
warm, fuzzy way.....if that would help?  Just a thought :-)

All best,
brynn


-----Original Message-----
From: C R
Sent: Sunday, January 22, 2017 3:30 AM
To: Bryce Harrington
Cc: inkscape-devel
Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug


Apologies. The intent of my "never say 'patches welcome' to a user unless they
said they want to contribute code" is not to suggest that we should not
encourage new users to contribute. I'm saying that's is not an effective way to
encourage contribution. If conveying problems to the mechanic who fixes your
car, and they tell you "well, fix it yourself", that does not encourage anyone
to become a mechanic. It encourages them to go elsewhere.

"Patches welcome" has become a flippant and dismissive way to say, "well, fix it
yourself". It's not something normal users can do without a great deal of work,
and learning to code is not easy. If we want to encourage non-coding users to
code, in order to fix problems in Inkscape, there are better ways to do that
than just saying "patches welcome" in response to their reports. That's all I'm
saying. :)
(Sorry for the double reply)
-C


On 22 Jan 2017 12:46 a.m., "Bryce Harrington" <[hidden email]> wrote:
On Sat, Jan 21, 2017 at 07:08:42PM +0000, C R wrote:
> We also must adopt a friendly attitude towards users, even when they
> are being unpleasant, or unhelpful. The words "patches welcome" should
> never *ever* be uttered at a user unless they are offering to
> contribute code. The bad press is not worth it.

This seems...  odd...  It raises a red flag in the back of my head.

Apologies that what follows is going to be a bit of a dissertation, one
the old timers will probably recognize.  It's purely philosophical so if
this sounds familiar feel free to skip to the end where the actual point
is.


In my thermodynamics courses in engineering college, we were drilled
into thinking of any process as a flow.  You draw a bubble around the
thingee you're going to study, then examine the inputs and outputs
crossing the bubble's boundaries.  If work goes in, you need to account
for heat coming out, else your thingee explodes causing mass death or
whatever.

This thinking applies broadly to a lot of other fields too.  Basically
it's just accounting work, making sure income and costs are in the
balance you need.

In traditional proprietary software, rather than heat or work, your
flowing substance is money.  End users provide a source of money, that
flows to the business owners, who pay the salaries of programmers to
introduce bugs and later take them out, and the programmers use the
money to buy games where they can make pretend explosions causing mass
death.  I won't go as far as to say money is a principle motivating
force for programmers, as it might be for say a stock broker or a car
salesman, but it is the grease that enables the whole machine to work.
The development costs have to be covered by the income from consumers,
so the process inherently needs to meet user needs, else the company
goes out of business.

With volunteer driven projects that provide products or services at no
cost to end users, the flowing substance is not money.  In volunteer
driven products money is more of a specialized tool for certain
problems, not what causes the project to actually run.  In volunteer
software projects like Inkscape, the flowing commodity is _patches_.
Like money, patches have value - it takes labor to create them, and even
though they're just intangible bits and bytes they produce changes that
have tangible value for users of the software.  Patches can be applied,
committed, tested, reverted, listed in release notes...  Having your
name as author of a popular patch can earn you attention and praise;
having your name on many good patches can earn respect and esteem;
achieving a particularly challenging patch can advance your learning and
perhaps open career opportunities you wouldn't otherwise have; creating
a perfect patch to solve a problem you care about can give you pride in
your work and self-fulfilment.  In a vibrant open source project,
patches in various states are flowing all over the place enabling
actions of all sorts to be done, and providing a whole variety of
rewards to everyone involved.  If the patch flow stops, the project dies
just as surely as the software company with no money.

However, there's a major flaw in this.  One you see hobbling a lot of
open source efforts.  This patch flow is great and all for making open
source projects work, but there is no effective role in it for end
users.  Since the software is given away for free, they don't even have
the consumer role that they would in the proprietary model.  Yes, there
is value to be gained in the respect earned from developing a product
that is widely used, in seeing fleeting but genuine expressions of
appreciation, yet that's more than offset by the inevitable (and "soul
crushing") complaints; regardless, the praise is an intangible, not a
flow commodity - goodwill doesn't fix bugs.  This situation is
extraordinarily ironic: the whole point of FOSS is to be open to users
participating in and steering projects to better meet their needs, yet
since users aren't part of the core value flow process, they effectively
have *less* influence or control.

It's even worse than that though.  Most FOSS projects - like Inkscape -
accept bug reports, feature requests, platform-specific packaging, and
so forth from end users.  A good analysis of a problem can actually be a
form of useful contribution, however the vast bulk of these tickets are
not near to that level, and are effectively just work requests -
i.e. costs.

A lot of open source projects look at this as just the price of the
model - users gain something of value for free, but only gain a say in
the process flow if they are actively participating.

So, there are two obvious approaches to this problem.  First would be to
encourage non-contributing users to become contributors and participate
in the process.  (And as a corollary ensure that new contributors are
welcomed and feel a sense of empowerment to participate in decision
making in relation to the patch flow).  The second approach would be to
expand the model to provide other more convenient ways for users to
have influence on the project.

I can see how "patches welcome" can be an irritating thing to be told.
I guess it'd be like complaining to the volunteer librarian that a book
you want is unavailable, and them saying "if you want it, feel free to
come shelve this pile of turned-in books."  You'd feel like a heel for
making demands of a volunteer, yet also feel like he was being an
asshole saying that when he could so easily just reach behind him and
find your book for you.  C R has a good point that the librarian
probably *could* get your help volunteering a bit, if they approached
you the right way, in a friendly and constructive manner.  That would be
an example of approach #1.  Approach #2 would be something like a
donation jar or a place to drop off used books for the library's book
sale.


For Inkscape, I feel it is imperative to work on both approaches, and
along with that we need to improve our internal patch flow - both volume
and quality.

So, #1 we need to welcome participation and stimulate more
contributions.  We need to encourage users to take that first step to
participate in the project, and to encourage drive-by contributors to
stick around.  There's a lot of techniques, but keeping the community
friendly and welcoming, as C R suggests, has been very effective for us
in the past.

I think it is also important to emphasize that producing Inkscape
requires much more than just code.  There are critical tasks vital if we
are to be successful at all, which have nothing to do with coding -
testing, evangelism, writing good documentation, translation,
infrastructure maintenance, website designing, user relations...  Any
one of these can become an Achille's Heel for the project if not tended
to, they're all important for moving our project forward and in my book
anyone doing any tasks in those roles should be considered an official
Inkscape developer.

Longer term is the #2 approach of expanding the model and creating novel
ways for users to influence the project.  This is where the funded
projects system fits in; it opens a new avenue for users to influence
us, by providing a mechanism for transmuting monetary donations into
patches.  And coupling it with specific development objectives, rather
than being a generic tip jar, serves the purpose of providing users some
control and influence within the patch flow, without needing to actually
write code.

Bryce






------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot





_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

Eduard Braun
In reply to this post by C R

While I agree we should try to motivate new contributions even by non-coders I disagree that a "patch welcome" is something we should never say.

A large project like Inkscape with limited developer resources must have the possibility to tell users "it's a nice idea an we'd definitely support it, but right now we don't have the manpower to implement it, so don't expect to see it fixed anytime soon unless you get active yourself or recruit somebody with the necessary skills".

As a user I find it much more frustrating if a feature request is accepted as a good idea but then without comment never worked on. This is the point where I feel ignored as a user an get the feeling that the devs work on whatever they like while ignoring the community!

Am 22. Januar 2017 11:30:40 schrieb C R [hidden email]:

Apologies. The intent of my "never say 'patches welcome' to a user unless they said they want to contribute code" is not to suggest that we should not encourage new users to contribute. I'm saying that's is not an effective way to encourage contribution. If conveying problems to the mechanic who fixes your car, and they tell you "well, fix it yourself", that does not encourage anyone to become a mechanic. It encourages them to go elsewhere.

"Patches welcome" has become a flippant and dismissive way to say, "well, fix it yourself". It's not something normal users can do without a great deal of work, and learning to code is not easy. If we want to encourage non-coding users to code, in order to fix problems in Inkscape, there are better ways to do that than just saying "patches welcome" in response to their reports. That's all I'm saying. :)
(Sorry for the double reply)
-C

On 22 Jan 2017 12:46 a.m., "Bryce Harrington" <[hidden email]> wrote:
On Sat, Jan 21, 2017 at 07:08:42PM +0000, C R wrote:
> We also must adopt a friendly attitude towards users, even when they
> are being unpleasant, or unhelpful. The words "patches welcome" should
> never *ever* be uttered at a user unless they are offering to
> contribute code. The bad press is not worth it.

This seems...  odd...  It raises a red flag in the back of my head.

Apologies that what follows is going to be a bit of a dissertation, one
the old timers will probably recognize.  It's purely philosophical so if
this sounds familiar feel free to skip to the end where the actual point
is.


In my thermodynamics courses in engineering college, we were drilled
into thinking of any process as a flow.  You draw a bubble around the
thingee you're going to study, then examine the inputs and outputs
crossing the bubble's boundaries.  If work goes in, you need to account
for heat coming out, else your thingee explodes causing mass death or
whatever.

This thinking applies broadly to a lot of other fields too.  Basically
it's just accounting work, making sure income and costs are in the
balance you need.

In traditional proprietary software, rather than heat or work, your
flowing substance is money.  End users provide a source of money, that
flows to the business owners, who pay the salaries of programmers to
introduce bugs and later take them out, and the programmers use the
money to buy games where they can make pretend explosions causing mass
death.  I won't go as far as to say money is a principle motivating
force for programmers, as it might be for say a stock broker or a car
salesman, but it is the grease that enables the whole machine to work.
The development costs have to be covered by the income from consumers,
so the process inherently needs to meet user needs, else the company
goes out of business.

With volunteer driven projects that provide products or services at no
cost to end users, the flowing substance is not money.  In volunteer
driven products money is more of a specialized tool for certain
problems, not what causes the project to actually run.  In volunteer
software projects like Inkscape, the flowing commodity is _patches_.
Like money, patches have value - it takes labor to create them, and even
though they're just intangible bits and bytes they produce changes that
have tangible value for users of the software.  Patches can be applied,
committed, tested, reverted, listed in release notes...  Having your
name as author of a popular patch can earn you attention and praise;
having your name on many good patches can earn respect and esteem;
achieving a particularly challenging patch can advance your learning and
perhaps open career opportunities you wouldn't otherwise have; creating
a perfect patch to solve a problem you care about can give you pride in
your work and self-fulfilment.  In a vibrant open source project,
patches in various states are flowing all over the place enabling
actions of all sorts to be done, and providing a whole variety of
rewards to everyone involved.  If the patch flow stops, the project dies
just as surely as the software company with no money.

However, there's a major flaw in this.  One you see hobbling a lot of
open source efforts.  This patch flow is great and all for making open
source projects work, but there is no effective role in it for end
users.  Since the software is given away for free, they don't even have
the consumer role that they would in the proprietary model.  Yes, there
is value to be gained in the respect earned from developing a product
that is widely used, in seeing fleeting but genuine expressions of
appreciation, yet that's more than offset by the inevitable (and "soul
crushing") complaints; regardless, the praise is an intangible, not a
flow commodity - goodwill doesn't fix bugs.  This situation is
extraordinarily ironic: the whole point of FOSS is to be open to users
participating in and steering projects to better meet their needs, yet
since users aren't part of the core value flow process, they effectively
have *less* influence or control.

It's even worse than that though.  Most FOSS projects - like Inkscape -
accept bug reports, feature requests, platform-specific packaging, and
so forth from end users.  A good analysis of a problem can actually be a
form of useful contribution, however the vast bulk of these tickets are
not near to that level, and are effectively just work requests -
i.e. costs.

A lot of open source projects look at this as just the price of the
model - users gain something of value for free, but only gain a say in
the process flow if they are actively participating.

So, there are two obvious approaches to this problem.  First would be to
encourage non-contributing users to become contributors and participate
in the process.  (And as a corollary ensure that new contributors are
welcomed and feel a sense of empowerment to participate in decision
making in relation to the patch flow).  The second approach would be to
expand the model to provide other more convenient ways for users to
have influence on the project.

I can see how "patches welcome" can be an irritating thing to be told.
I guess it'd be like complaining to the volunteer librarian that a book
you want is unavailable, and them saying "if you want it, feel free to
come shelve this pile of turned-in books."  You'd feel like a heel for
making demands of a volunteer, yet also feel like he was being an
asshole saying that when he could so easily just reach behind him and
find your book for you.  C R has a good point that the librarian
probably *could* get your help volunteering a bit, if they approached
you the right way, in a friendly and constructive manner.  That would be
an example of approach #1.  Approach #2 would be something like a
donation jar or a place to drop off used books for the library's book
sale.


For Inkscape, I feel it is imperative to work on both approaches, and
along with that we need to improve our internal patch flow - both volume
and quality.

So, #1 we need to welcome participation and stimulate more
contributions.  We need to encourage users to take that first step to
participate in the project, and to encourage drive-by contributors to
stick around.  There's a lot of techniques, but keeping the community
friendly and welcoming, as C R suggests, has been very effective for us
in the past.

I think it is also important to emphasize that producing Inkscape
requires much more than just code.  There are critical tasks vital if we
are to be successful at all, which have nothing to do with coding -
testing, evangelism, writing good documentation, translation,
infrastructure maintenance, website designing, user relations...  Any
one of these can become an Achille's Heel for the project if not tended
to, they're all important for moving our project forward and in my book
anyone doing any tasks in those roles should be considered an official
Inkscape developer.

Longer term is the #2 approach of expanding the model and creating novel
ways for users to influence the project.  This is where the funded
projects system fits in; it opens a new avenue for users to influence
us, by providing a mechanism for transmuting monetary donations into
patches.  And coupling it with specific development objectives, rather
than being a generic tip jar, serves the purpose of providing users some
control and influence within the patch flow, without needing to actually
write code.

Bryce

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line height bug

C R


A large project like Inkscape with limited developer resources must have the possibility to tell users "it's a nice idea an we'd definitely support it, but right now we don't have the manpower to implement it, so don't expect to see it fixed anytime soon unless you get active yourself or recruit somebody with the necessary skills".


I recommend saying precisely that instead of "patches welcome". It explains better the situation, and is less dismissive.




As a user I find it much more frustrating if a feature request is accepted as a good idea but then without comment never worked on. This is the point where I feel ignored as a user an get the feeling that the devs work on whatever they like while ignoring the community!

Users requesting features should do so via the bug tracker wish list items as well as in IRC, and mailing list. If someone suggests something good, it should immediately be put in the bug tracker.
It's not really an either or situation, to my mind. There are good ways of informing users of the situation.

I maintain that "patches welcome" is not one of them.

On 22 Jan 2017 4:12 p.m., "Eduard Braun" <[hidden email]> wrote:

While I agree we should try to motivate new contributions even by non-coders I disagree that a "patch welcome" is something we should never say.

A large project like Inkscape with limited developer resources must have the possibility to tell users "it's a nice idea an we'd definitely support it, but right now we don't have the manpower to implement it, so don't expect to see it fixed anytime soon unless you get active yourself or recruit somebody with the necessary skills".

As a user I find it much more frustrating if a feature request is accepted as a good idea but then without comment never worked on. This is the point where I feel ignored as a user an get the feeling that the devs work on whatever they like while ignoring the community!

Am 22. Januar 2017 11:30:40 schrieb C R [hidden email]:

Apologies. The intent of my "never say 'patches welcome' to a user unless they said they want to contribute code" is not to suggest that we should not encourage new users to contribute. I'm saying that's is not an effective way to encourage contribution. If conveying problems to the mechanic who fixes your car, and they tell you "well, fix it yourself", that does not encourage anyone to become a mechanic. It encourages them to go elsewhere.

"Patches welcome" has become a flippant and dismissive way to say, "well, fix it yourself". It's not something normal users can do without a great deal of work, and learning to code is not easy. If we want to encourage non-coding users to code, in order to fix problems in Inkscape, there are better ways to do that than just saying "patches welcome" in response to their reports. That's all I'm saying. :)
(Sorry for the double reply)
-C

On 22 Jan 2017 12:46 a.m., "Bryce Harrington" <[hidden email]> wrote:
On Sat, Jan 21, 2017 at 07:08:42PM +0000, C R wrote:
> We also must adopt a friendly attitude towards users, even when they
> are being unpleasant, or unhelpful. The words "patches welcome" should
> never *ever* be uttered at a user unless they are offering to
> contribute code. The bad press is not worth it.

This seems...  odd...  It raises a red flag in the back of my head.

Apologies that what follows is going to be a bit of a dissertation, one
the old timers will probably recognize.  It's purely philosophical so if
this sounds familiar feel free to skip to the end where the actual point
is.


In my thermodynamics courses in engineering college, we were drilled
into thinking of any process as a flow.  You draw a bubble around the
thingee you're going to study, then examine the inputs and outputs
crossing the bubble's boundaries.  If work goes in, you need to account
for heat coming out, else your thingee explodes causing mass death or
whatever.

This thinking applies broadly to a lot of other fields too.  Basically
it's just accounting work, making sure income and costs are in the
balance you need.

In traditional proprietary software, rather than heat or work, your
flowing substance is money.  End users provide a source of money, that
flows to the business owners, who pay the salaries of programmers to
introduce bugs and later take them out, and the programmers use the
money to buy games where they can make pretend explosions causing mass
death.  I won't go as far as to say money is a principle motivating
force for programmers, as it might be for say a stock broker or a car
salesman, but it is the grease that enables the whole machine to work.
The development costs have to be covered by the income from consumers,
so the process inherently needs to meet user needs, else the company
goes out of business.

With volunteer driven projects that provide products or services at no
cost to end users, the flowing substance is not money.  In volunteer
driven products money is more of a specialized tool for certain
problems, not what causes the project to actually run.  In volunteer
software projects like Inkscape, the flowing commodity is _patches_.
Like money, patches have value - it takes labor to create them, and even
though they're just intangible bits and bytes they produce changes that
have tangible value for users of the software.  Patches can be applied,
committed, tested, reverted, listed in release notes...  Having your
name as author of a popular patch can earn you attention and praise;
having your name on many good patches can earn respect and esteem;
achieving a particularly challenging patch can advance your learning and
perhaps open career opportunities you wouldn't otherwise have; creating
a perfect patch to solve a problem you care about can give you pride in
your work and self-fulfilment.  In a vibrant open source project,
patches in various states are flowing all over the place enabling
actions of all sorts to be done, and providing a whole variety of
rewards to everyone involved.  If the patch flow stops, the project dies
just as surely as the software company with no money.

However, there's a major flaw in this.  One you see hobbling a lot of
open source efforts.  This patch flow is great and all for making open
source projects work, but there is no effective role in it for end
users.  Since the software is given away for free, they don't even have
the consumer role that they would in the proprietary model.  Yes, there
is value to be gained in the respect earned from developing a product
that is widely used, in seeing fleeting but genuine expressions of
appreciation, yet that's more than offset by the inevitable (and "soul
crushing") complaints; regardless, the praise is an intangible, not a
flow commodity - goodwill doesn't fix bugs.  This situation is
extraordinarily ironic: the whole point of FOSS is to be open to users
participating in and steering projects to better meet their needs, yet
since users aren't part of the core value flow process, they effectively
have *less* influence or control.

It's even worse than that though.  Most FOSS projects - like Inkscape -
accept bug reports, feature requests, platform-specific packaging, and
so forth from end users.  A good analysis of a problem can actually be a
form of useful contribution, however the vast bulk of these tickets are
not near to that level, and are effectively just work requests -
i.e. costs.

A lot of open source projects look at this as just the price of the
model - users gain something of value for free, but only gain a say in
the process flow if they are actively participating.

So, there are two obvious approaches to this problem.  First would be to
encourage non-contributing users to become contributors and participate
in the process.  (And as a corollary ensure that new contributors are
welcomed and feel a sense of empowerment to participate in decision
making in relation to the patch flow).  The second approach would be to
expand the model to provide other more convenient ways for users to
have influence on the project.

I can see how "patches welcome" can be an irritating thing to be told.
I guess it'd be like complaining to the volunteer librarian that a book
you want is unavailable, and them saying "if you want it, feel free to
come shelve this pile of turned-in books."  You'd feel like a heel for
making demands of a volunteer, yet also feel like he was being an
asshole saying that when he could so easily just reach behind him and
find your book for you.  C R has a good point that the librarian
probably *could* get your help volunteering a bit, if they approached
you the right way, in a friendly and constructive manner.  That would be
an example of approach #1.  Approach #2 would be something like a
donation jar or a place to drop off used books for the library's book
sale.


For Inkscape, I feel it is imperative to work on both approaches, and
along with that we need to improve our internal patch flow - both volume
and quality.

So, #1 we need to welcome participation and stimulate more
contributions.  We need to encourage users to take that first step to
participate in the project, and to encourage drive-by contributors to
stick around.  There's a lot of techniques, but keeping the community
friendly and welcoming, as C R suggests, has been very effective for us
in the past.

I think it is also important to emphasize that producing Inkscape
requires much more than just code.  There are critical tasks vital if we
are to be successful at all, which have nothing to do with coding -
testing, evangelism, writing good documentation, translation,
infrastructure maintenance, website designing, user relations...  Any
one of these can become an Achille's Heel for the project if not tended
to, they're all important for moving our project forward and in my book
anyone doing any tasks in those roles should be considered an official
Inkscape developer.

Longer term is the #2 approach of expanding the model and creating novel
ways for users to influence the project.  This is where the funded
projects system fits in; it opens a new avenue for users to influence
us, by providing a mechanism for transmuting monetary donations into
patches.  And coupling it with specific development objectives, rather
than being a generic tip jar, serves the purpose of providing users some
control and influence within the patch flow, without needing to actually
write code.

Bryce

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
C R
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: User Involvement Was: Post-Mortum: Line heightbug

C R
In reply to this post by Brynn


On 22 Jan 2017 3:50 p.m., "brynn" <[hidden email]> wrote:
"Patches welcome" has become a flippant and dismissive way to say, "well, fix it yourself".

Most of my experience helping Inkscape users is in forums (approx 8 years), as opposed to the mailing list (approx 2 or 3 years).  I've never seen this suggested in a flippant or dismissive way. 

Okay... I must be imagining it. ;) To be fair, it happens much less often in Inkscape IRC than in others. The few times it happened recently, there was a quick apology, so that helped too.


Even for people who come on strong or maybe even are rantish about their complaint, we try to give them all the info we have to address their specific issues (including manual references and links to relevant bug reports and  website and wiki pages).

All of which is better than "patches welcome".

If they continue with their complaints, we remind them that Inkscape being open source, is being developed almost entirely by volunteers, who have families and day-jobs, and offline lives, in their spare time.

Which is flawless. Notice how much better that is than "patches welcome"? :)

We give them info about what open source means, in case they don't already know, and explain that development is different than it is for proprietary programs.  Recently it's been nice to be able to suggest funded development, since Bryce put together all that info.

Definitely agree.


Then if they still are persistent in complaining, finally, we ask if they have any programming skills and might have some time and energy to create or fix whatever the issue is, and including links to development parts of the website.

That's also the ideal way to handle it, from my perspective. That's encouragement and in the face of adversity, and it's a perfect response as well.


I know that often we are tired of hearing the same complaints over and over, and it's all the more frustrating to give the same answers that we have so many times before. 

Agree.


And we might be wishing we could easily dismiss them.  But I've never seen anyone actually say what they are thinking.

"Patches welcome", for me falls under the dismissive category. Compare it to all you just said above and there really is no comparison. 


Or I don't know, maybe it happens in mailing list threads that I don't read?  I don't often participate on IRC, so maybe that's where this has happened?  It seems like IRC has fast moving discussions, where people don't seem to have time for well-thought, detailed responses.  If that's the case, we should probably try to find some other way to offer the user an opportunity to become more involved.

Yes, mostly in IRC, I find.


I could see a webpage....or a section of a webpage, which has kind of a pitch or invitation.  Without looking, I don't remember specifics, but I think parts of the faq (user faq on the website) already do this.  So it could be made into a page or section of a page.  Since people have all different kind of issues, we couldn't provide the support info.  But it could include generalized support info, along with everything else I mentioned above.  And then when we find ourselves thinking "patches welcome", we could link to it, rather than type it all out, every time.

Sure, I think that's much better. 



Or would that be too impersonal? 

Well, possibly... But it's still better than "patches welcome". :)

If the Inkscape project is known for being a friendly community (as someone said earlier) it could be written in sort of a warm, fuzzy way.....if that would help?  Just a thought :-)

Yes, I said this, and others do too. Even the ones fed up with Open Source agree we are "super nice". And again, this is one of the main reasons why I stick around and contribute. :)

-C



All best,
brynn


-----Original Message----- From: C R
Sent: Sunday, January 22, 2017 3:30 AM
To: Bryce Harrington
Cc: inkscape-devel

Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug


Apologies. The intent of my "never say 'patches welcome' to a user unless they said they want to contribute code" is not to suggest that we should not encourage new users to contribute. I'm saying that's is not an effective way to encourage contribution. If conveying problems to the mechanic who fixes your car, and they tell you "well, fix it yourself", that does not encourage anyone to become a mechanic. It encourages them to go elsewhere.

"Patches welcome" has become a flippant and dismissive way to say, "well, fix it yourself". It's not something normal users can do without a great deal of work, and learning to code is not easy. If we want to encourage non-coding users to code, in order to fix problems in Inkscape, there are better ways to do that than just saying "patches welcome" in response to their reports. That's all I'm saying. :)
(Sorry for the double reply)
-C


On 22 Jan 2017 12:46 a.m., "Bryce Harrington" <[hidden email]> wrote:
On Sat, Jan 21, 2017 at 07:08:42PM +0000, C R wrote:
We also must adopt a friendly attitude towards users, even when they
are being unpleasant, or unhelpful. The words "patches welcome" should
never *ever* be uttered at a user unless they are offering to
contribute code. The bad press is not worth it.

This seems...  odd...  It raises a red flag in the back of my head.

Apologies that what follows is going to be a bit of a dissertation, one
the old timers will probably recognize.  It's purely philosophical so if
this sounds familiar feel free to skip to the end where the actual point
is.


In my thermodynamics courses in engineering college, we were drilled
into thinking of any process as a flow.  You draw a bubble around the
thingee you're going to study, then examine the inputs and outputs
crossing the bubble's boundaries.  If work goes in, you need to account
for heat coming out, else your thingee explodes causing mass death or
whatever.

This thinking applies broadly to a lot of other fields too.  Basically
it's just accounting work, making sure income and costs are in the
balance you need.

In traditional proprietary software, rather than heat or work, your
flowing substance is money.  End users provide a source of money, that
flows to the business owners, who pay the salaries of programmers to
introduce bugs and later take them out, and the programmers use the
money to buy games where they can make pretend explosions causing mass
death.  I won't go as far as to say money is a principle motivating
force for programmers, as it might be for say a stock broker or a car
salesman, but it is the grease that enables the whole machine to work.
The development costs have to be covered by the income from consumers,
so the process inherently needs to meet user needs, else the company
goes out of business.

With volunteer driven projects that provide products or services at no
cost to end users, the flowing substance is not money.  In volunteer
driven products money is more of a specialized tool for certain
problems, not what causes the project to actually run.  In volunteer
software projects like Inkscape, the flowing commodity is _patches_.
Like money, patches have value - it takes labor to create them, and even
though they're just intangible bits and bytes they produce changes that
have tangible value for users of the software.  Patches can be applied,
committed, tested, reverted, listed in release notes...  Having your
name as author of a popular patch can earn you attention and praise;
having your name on many good patches can earn respect and esteem;
achieving a particularly challenging patch can advance your learning and
perhaps open career opportunities you wouldn't otherwise have; creating
a perfect patch to solve a problem you care about can give you pride in
your work and self-fulfilment.  In a vibrant open source project,
patches in various states are flowing all over the place enabling
actions of all sorts to be done, and providing a whole variety of
rewards to everyone involved.  If the patch flow stops, the project dies
just as surely as the software company with no money.

However, there's a major flaw in this.  One you see hobbling a lot of
open source efforts.  This patch flow is great and all for making open
source projects work, but there is no effective role in it for end
users.  Since the software is given away for free, they don't even have
the consumer role that they would in the proprietary model.  Yes, there
is value to be gained in the respect earned from developing a product
that is widely used, in seeing fleeting but genuine expressions of
appreciation, yet that's more than offset by the inevitable (and "soul
crushing") complaints; regardless, the praise is an intangible, not a
flow commodity - goodwill doesn't fix bugs.  This situation is
extraordinarily ironic: the whole point of FOSS is to be open to users
participating in and steering projects to better meet their needs, yet
since users aren't part of the core value flow process, they effectively
have *less* influence or control.

It's even worse than that though.  Most FOSS projects - like Inkscape -
accept bug reports, feature requests, platform-specific packaging, and
so forth from end users.  A good analysis of a problem can actually be a
form of useful contribution, however the vast bulk of these tickets are
not near to that level, and are effectively just work requests -
i.e. costs.

A lot of open source projects look at this as just the price of the
model - users gain something of value for free, but only gain a say in
the process flow if they are actively participating.

So, there are two obvious approaches to this problem.  First would be to
encourage non-contributing users to become contributors and participate
in the process.  (And as a corollary ensure that new contributors are
welcomed and feel a sense of empowerment to participate in decision
making in relation to the patch flow).  The second approach would be to
expand the model to provide other more convenient ways for users to
have influence on the project.

I can see how "patches welcome" can be an irritating thing to be told.
I guess it'd be like complaining to the volunteer librarian that a book
you want is unavailable, and them saying "if you want it, feel free to
come shelve this pile of turned-in books."  You'd feel like a heel for
making demands of a volunteer, yet also feel like he was being an
asshole saying that when he could so easily just reach behind him and
find your book for you.  C R has a good point that the librarian
probably *could* get your help volunteering a bit, if they approached
you the right way, in a friendly and constructive manner.  That would be
an example of approach #1.  Approach #2 would be something like a
donation jar or a place to drop off used books for the library's book
sale.


For Inkscape, I feel it is imperative to work on both approaches, and
along with that we need to improve our internal patch flow - both volume
and quality.

So, #1 we need to welcome participation and stimulate more
contributions.  We need to encourage users to take that first step to
participate in the project, and to encourage drive-by contributors to
stick around.  There's a lot of techniques, but keeping the community
friendly and welcoming, as C R suggests, has been very effective for us
in the past.

I think it is also important to emphasize that producing Inkscape
requires much more than just code.  There are critical tasks vital if we
are to be successful at all, which have nothing to do with coding -
testing, evangelism, writing good documentation, translation,
infrastructure maintenance, website designing, user relations...  Any
one of these can become an Achille's Heel for the project if not tended
to, they're all important for moving our project forward and in my book
anyone doing any tasks in those roles should be considered an official
Inkscape developer.

Longer term is the #2 approach of expanding the model and creating novel
ways for users to influence the project.  This is where the funded
projects system fits in; it opens a new avenue for users to influence
us, by providing a mechanism for transmuting monetary donations into
patches.  And coupling it with specific development objectives, rather
than being a generic tip jar, serves the purpose of providing users some
control and influence within the patch flow, without needing to actually
write code.

Bryce






------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot





_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
123
Loading...