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
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" <doctormo@...400...> 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:
- The bug wasn't discovered in time
- The bug wasn't reported in time
- The reported bug wasn't triaged in time
- The bug wasn't prioritised as important
- 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 01/21/2017 05:55 AM, Martin Owens wrote:
There's a couple of possibilities:
- The bug wasn't discovered in time
- The bug wasn't reported in time
- The reported bug wasn't triaged in time
- The bug wasn't prioritised as important
- 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.
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 <marc@...3062...> wrote:
On 01/21/2017 05:55 AM, Martin Owens wrote:
There's a couple of possibilities:
- The bug wasn't discovered in time
- The bug wasn't reported in time
- The reported bug wasn't triaged in time
- The bug wasn't prioritised as important
- 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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
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
On Sat, 21 Jan 2017 19:08:42 +0000 C R <cajhne@...400...> 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
Am 21.01.2017 um 23:56 schrieb Terry Brown:
On Sat, 21 Jan 2017 19:08:42 +0000 C R <cajhne@...400...> 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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: inkscape-devel@lists.sourceforge.net 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 <cajhne@...400...> 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 Inkscape-devel@lists.sourceforge.net 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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" <bryce@...961...> 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
"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" <bryce@...961...> 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 22 Jan 2017 3:50 p.m., "brynn" <brynn@...3133...> 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" <bryce@...961...> 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Jan 22, 2017 at 08:50:49AM -0700, brynn 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.
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 :-)
I think that's a brilliant idea. You're right that we have written bits along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce
I think that's a brilliant idea. You're right that we have written bits
along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce __________________________________________________
Yeah sure, as long as we're waiting for OSUOSL, I have time to spare. I'll have to look in the FAQ to see what's left still there. Because now that I think of it, a lot of it has been brought to the Contribute page already, and some on the Promote page.
https://inkscape.org/en/contribute/ https://inkscape.org/en/contribute/promote/
Should we split those sections up, and add more to them? I think what might be missing, to address this concern, is language that perhaps is more inviting (and maybe more warm and fuzzy?) as opposed to strictly informational.
I know we had a report recently, where someone thought the info about helping with the website should be on the Contribute page, rather than Promote. I originally put it on Promote, because I was thinking that's what the website does, is promote Inkscape. Plus, it made a way to break into 2 pages evenly, while all on the same page, it's too long.
Anyway, maybe there's a better way to organize all that?
Ok, the only thing left in the FAQ is this:
https://inkscape.org/en/learn/faq/#how-communicate-effectively-throughout-in...
which I deliberately left there, thinking it should probably be deleted, but not wanting to make that decision alone. I think we can definitely use that first paragraph. And maybe some other parts too? Since we have the CoC, we can probably lose the flamewar part.
Hhmm....I'm thinking of an introduction to the Contribute page, which contains most of that info. Section title "So, You Want to Contribute to Inkscape? Here's how to get started" More warm and fuzzy, but maybe too corny?
C R, jump in with comments too :-)
All best, brynn PS - another thought - Maybe the CoC could have some language for bringing new people in without saying "patches welcome"?
-----Original Message----- From: Bryce Harrington Sent: Sunday, January 22, 2017 7:51 PM To: brynn Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 22, 2017 at 08:50:49AM -0700, brynn 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.
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 :-)
I think that's a brilliant idea. You're right that we have written bits along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce
On Mon, Jan 23, 2017 at 11:03:31PM -0700, brynn wrote:
I think that's a brilliant idea. You're right that we have written bits
along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce __________________________________________________
Yeah sure, as long as we're waiting for OSUOSL, I have time to spare. I'll have to look in the FAQ to see what's left still there. Because now that I think of it, a lot of it has been brought to the Contribute page already, and some on the Promote page.
https://inkscape.org/en/contribute/ https://inkscape.org/en/contribute/promote/
Ah, guess it's been a while since I've browsed the website. It looks like most of what I am thinking we should have, we already have! So there's a lot of good work already done, but of course always room to improve. A few notes below...
Should we split those sections up, and add more to them? I think what might be missing, to address this concern, is language that perhaps is more inviting (and maybe more warm and fuzzy?) as opposed to strictly informational.
The sections look good. Would it make sense to reverse the order? I.e. I imagine more of this page's visitors will have skills relevant to items towards the bottom of the list, so move those up top? And people looking to code for Inkscape likely will be drawn to the Develop top level menu already, so the link to it from the Contribute page doesn't need to be prominent.
I'm in favor of keeping wording friendly, but actually the page looks ok to me as it is -- admittedly I'm probably not the best to judge. There's benefit to keeping Contribute concise, but perhaps friendlier language could be placed on the sub-pages. (E.g. the opening sentence of Contribute and Promote ought to be more engaging.)
I really like the Community To-Do List page (contribute/to-do-list) and imagine potential contributors may be drawn here looking for specific needs. Expanding this list and keeping it to well-defined items, and seeded with good entry-level work that doesn't require a lot of Inkscape-specific know-how could be very beneficial.
Next I'd put the Non-Coding section, and again I'd reverse the order: Promote first, then Translations, Bugs, and Testing. (I would also omit the 'Non-Coding' section title, so we're not giving the impression that the work is less important than coding or something.) There should also be a section on 'Helping Other Inkscape Users'.
The Promote section should have a better description written for it, to make it more engaging. The Promote subpage needs some work - I'd focus this to just the last part of the page, the stuff under "Spread the Word!" Everything else on that page should be moved or maybe just dropped; some of it might fit under "Show Off your Inkscape Artwork".
The Helping Other Inkscape Users should be moved from the Promote page to its own page. There is a lot of opportunities for contributing to the Inkscape project in the form of technical support and user assistance, participating on Inkscape Forum, etc. and we should properly highlight that area of work.
The Translations section looks fine. The Translation subpage looks very good too. It's got a friendly and welcoming opening paragraph, is very specific with initial tasks for onboarding, and then has a list of very specific tasks and guidelines making it a solid reference. This subpage is a good one to model for all the other subpages.
The Bugs section I think could be made more specific to just Review and Verify Existing Bug Reports. That's what we really need help with, and in terms of helping the project reporting bugs is really more of a subset of the Testing task.
For Testing, I like that we have guidelines, and it's good that this section links to them. The contribute/testing page is marked out of date though. "Testing" can mean a spectrum of different activities, so perhaps there's some opportunities here to give some more specific actions. This is a key area we need help, and is also a perfect place for new technical folk to get their feet wet, so improvements to this page could have big long term benefits to the project.
The Working with Code section kind of duplicates what is on the Develop page, and I think could be reduced to just "Inkscape Core Development" (with the link to the Develop page), and "Website Development" (with a link to a landing page with a friendly introduction to the website development). The subsection on Packaging Inkscape could be moved to the end of the Develop page.
I know we had a report recently, where someone thought the info about helping with the website should be on the Contribute page, rather than Promote. I originally put it on Promote, because I was thinking that's what the website does, is promote Inkscape.
Sure that seems logical, although I think I agree the Promote page should be geared more for evangelizing activities, whereas in practice website work tends to be more about wordsmithing and page design (with some HTML/Django technicalities tossed in for fun).
Ok, the only thing left in the FAQ is this:
https://inkscape.org/en/learn/faq/#how-communicate-effectively-throughout-in...
which I deliberately left there, thinking it should probably be deleted, but not wanting to make that decision alone. I think we can definitely use that first paragraph. And maybe some other parts too? Since we have the CoC, we can probably lose the flamewar part.
Right, much of that is pretty dated. Maybe something of use can still be made of some of it but I don't think it needs to live in the FAQ. If you need a place to move it, you could stick it on http://wiki.inkscape.org/wiki/index.php/OtherGoals. I've already got a todo to cleanup that page some day.
Hhmm....I'm thinking of an introduction to the Contribute page, which contains most of that info. Section title "So, You Want to Contribute to Inkscape? Here's how to get started" More warm and fuzzy, but maybe too corny?
C R, jump in with comments too :-)
Thanks! Sorry for the lengthy reply.
All best, brynn PS - another thought - Maybe the CoC could have some language for bringing new people in without saying "patches welcome"?
Nah, I'd guess by the time a reader got to the CoC they would have already seen enough of Inkscape to already feel appropriately welcome. :-)
Bryce
-----Original Message----- From: Bryce Harrington Sent: Sunday, January 22, 2017 7:51 PM To: brynn Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 22, 2017 at 08:50:49AM -0700, brynn 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.
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 :-)
I think that's a brilliant idea. You're right that we have written bits along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce
(Martin copied in, just fyi, no specific reply needed)
Sorry, fairly long reply (tldr for most readers)
Should we split those sections up, and add more to them? I think what might be missing, to address this concern, is language that perhaps is more inviting (and maybe more warm and fuzzy?) as opposed to strictly informational.
The sections look good. Would it make sense to reverse the order? I.e. I imagine more of this page's visitors will have skills relevant to items towards the bottom of the list, so move those up top? And people looking to code for Inkscape likely will be drawn to the Develop top level menu already, so the link to it from the Contribute page doesn't need to be prominent. ____________________
That's interesting thought. I seem to recall my first version of the page, the sections were reversed. I was thinking - list them from easiest to hardest, or things that take less skill, to things that take more skill.
But someone else said to have the coding stuff at the top, because that's what the project needs the most. I'm personally neutral on this, and I'm happy to make whatever changes are needed.
(E.g. the opening sentence
of Contribute and Promote ought to be more engaging.)
I agree that would be a good idea, and I'll make a rough draft, maybe using the first paragraph of that last bit of info in the wiki (which I like). But C R has offered to make suggestions too. Should I just make working page, that we could all access and tweak on? I don't remember if C R is a website editor.
I really like the Community To-Do List page (contribute/to-do-list) and
imagine potential contributors may be drawn here looking for specific needs. Expanding this list and keeping it to well-defined items, and seeded with good entry-level work that doesn't require a lot of Inkscape-specific know-how could be very beneficial.
I had hoped that this would be a useful page. But no one seems to be interested in those projects that are listed. Maybe because a lot of them need significant experience with the project, and newbies coming in might feel like they don't have enough experience yet. Nevertheless, that page could handle a few more projects, if anyone knows of any or needs help with something. Just let us know.
Next I'd put the Non-Coding section, and again I'd reverse the order:
Promote first, then Translations, Bugs, and Testing. (I would also omit the 'Non-Coding' section title, so we're not giving the impression that the work is less important than coding or something.) There should also be a section on 'Helping Other Inkscape Users'.
I don't see "non-coding" as less important. When I read the title, I get excited, because here's something I could actually help with. It doesn't make me feel bad about myself, and I think my self-esteem is fairly intact. But I understand that "non-" is a negative, and something more positive might be better. I just can't think of a good alternative. Suggestions? What's the opposite of coding or programming or hacking? "Other" would probably be too vague.
I like the idea of a section title 'Helping Other Inkscape Users'. Oh geez, talk about not remembering what's on the website. Now that I look, I see that there already is a section with that title, on the Promote page.
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
The Promote section should have a better description written for it, to
make it more engaging. The Promote subpage needs some work - I'd focus this to just the last part of the page, the stuff under "Spread the Word!" Everything else on that page should be moved or maybe just dropped; some of it might fit under "Show Off your Inkscape Artwork".
Hhmm, but just the last part of the page (Spread the Word!) is not enough content to stand alone on a page (well it could, but more would be better, if possible). I can see moving the Web Presence and Use Your Graphic Skills to the Contribute page. It would make it a little long. But Promote page (or whatever better name for it) could hold Help Other Users and Spread the Word, without being too short.
The Helping Other Inkscape Users should be moved from the Promote page
to its own page. There is a lot of opportunities for contributing to the Inkscape project in the form of technical support and user assistance, participating on Inkscape Forum, etc. and we should properly highlight that area of work.
That section is a little longer than Spread the Word, but still makes for a pretty short page, by itself. I guess I wouldn't have any objections. But if it could be expanded, would be better, imo. I just can't think of any other ways for helping other users.
The Translations section looks fine. The Translation subpage looks very
good too. It's got a friendly and welcoming opening paragraph, is very specific with initial tasks for onboarding, and then has a list of very specific tasks and guidelines making it a solid reference. This subpage is a good one to model for all the other subpages.
Yes, I think Maren has tweaked that page to perfection. Unfortunately, I think she wants to take a break from website editing, except for translation-related things. I'll try to use it as a guide for the others. And if anyone else wants to help, of course let us know!
The Bugs section I think could be made more specific to just Review and
Verify Existing Bug Reports. That's what we really need help with, and in terms of helping the project reporting bugs is really more of a subset of the Testing task.
For the Bugs section, Testing, and Working with Code, I don't have the knowledge for making all the changes you described. I can move Report Bugs into the Testing section. But I can't make any of the other changes to Testing that you mentioned. I just don't have that knowledge.
The Working with Code section kind of duplicates what is on the Develop
page, and I think could be reduced to just "Inkscape Core Development" (with the link to the Develop page), and "Website Development" (with a link to a landing page with a friendly introduction to the website development). The subsection on Packaging Inkscape could be moved to the end of the Develop page.
Well, the entire purpose of this page is just to give a brief preview of what people will find in all the sub-pages. There are a couple of places in the website where the introduction is very similar to the sub-page, and that's one of them. But I haven't thought of any better way to do it, for those couple of places. I think it would be confusing not to follow the same kind of format throughout the site - brief introduction on top level page, more details on sub-page.
But, I still agree that some of it can probably be more friendly and inviting. For example, "Pease see Develop page...." is not all that interesting. But I just don't have the right kind of background or knowledge to do any better. Don't know any catch phrases or trendy lingo.
I can move Packaging to the top level Develop page, and delete the Write Extensions section, if you like. I don't follow your logic, but it's probably because I don't understand programming.
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Thanks, brynn
-----Original Message----- From: Bryce Harrington Sent: Saturday, January 28, 2017 10:12 PM To: brynn Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Mon, Jan 23, 2017 at 11:03:31PM -0700, brynn wrote:
I think that's a brilliant idea. You're right that we have written bits
along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce __________________________________________________
Yeah sure, as long as we're waiting for OSUOSL, I have time to spare. I'll have to look in the FAQ to see what's left still there. Because now that I think of it, a lot of it has been brought to the Contribute page already, and some on the Promote page.
https://inkscape.org/en/contribute/ https://inkscape.org/en/contribute/promote/
Ah, guess it's been a while since I've browsed the website. It looks like most of what I am thinking we should have, we already have! So there's a lot of good work already done, but of course always room to improve. A few notes below...
Should we split those sections up, and add more to them? I think what might be missing, to address this concern, is language that perhaps is more inviting (and maybe more warm and fuzzy?) as opposed to strictly informational.
The sections look good. Would it make sense to reverse the order? I.e. I imagine more of this page's visitors will have skills relevant to items towards the bottom of the list, so move those up top? And people looking to code for Inkscape likely will be drawn to the Develop top level menu already, so the link to it from the Contribute page doesn't need to be prominent.
I'm in favor of keeping wording friendly, but actually the page looks ok to me as it is -- admittedly I'm probably not the best to judge. There's benefit to keeping Contribute concise, but perhaps friendlier language could be placed on the sub-pages. (E.g. the opening sentence of Contribute and Promote ought to be more engaging.)
I really like the Community To-Do List page (contribute/to-do-list) and imagine potential contributors may be drawn here looking for specific needs. Expanding this list and keeping it to well-defined items, and seeded with good entry-level work that doesn't require a lot of Inkscape-specific know-how could be very beneficial.
Next I'd put the Non-Coding section, and again I'd reverse the order: Promote first, then Translations, Bugs, and Testing. (I would also omit the 'Non-Coding' section title, so we're not giving the impression that the work is less important than coding or something.) There should also be a section on 'Helping Other Inkscape Users'.
The Promote section should have a better description written for it, to make it more engaging. The Promote subpage needs some work - I'd focus this to just the last part of the page, the stuff under "Spread the Word!" Everything else on that page should be moved or maybe just dropped; some of it might fit under "Show Off your Inkscape Artwork".
The Helping Other Inkscape Users should be moved from the Promote page to its own page. There is a lot of opportunities for contributing to the Inkscape project in the form of technical support and user assistance, participating on Inkscape Forum, etc. and we should properly highlight that area of work.
The Translations section looks fine. The Translation subpage looks very good too. It's got a friendly and welcoming opening paragraph, is very specific with initial tasks for onboarding, and then has a list of very specific tasks and guidelines making it a solid reference. This subpage is a good one to model for all the other subpages.
The Bugs section I think could be made more specific to just Review and Verify Existing Bug Reports. That's what we really need help with, and in terms of helping the project reporting bugs is really more of a subset of the Testing task.
For Testing, I like that we have guidelines, and it's good that this section links to them. The contribute/testing page is marked out of date though. "Testing" can mean a spectrum of different activities, so perhaps there's some opportunities here to give some more specific actions. This is a key area we need help, and is also a perfect place for new technical folk to get their feet wet, so improvements to this page could have big long term benefits to the project.
The Working with Code section kind of duplicates what is on the Develop page, and I think could be reduced to just "Inkscape Core Development" (with the link to the Develop page), and "Website Development" (with a link to a landing page with a friendly introduction to the website development). The subsection on Packaging Inkscape could be moved to the end of the Develop page.
I know we had a report recently, where someone thought the info about helping with the website should be on the Contribute page, rather than Promote. I originally put it on Promote, because I was thinking that's what the website does, is promote Inkscape.
Sure that seems logical, although I think I agree the Promote page should be geared more for evangelizing activities, whereas in practice website work tends to be more about wordsmithing and page design (with some HTML/Django technicalities tossed in for fun).
Ok, the only thing left in the FAQ is this:
https://inkscape.org/en/learn/faq/#how-communicate-effectively-throughout-in...
which I deliberately left there, thinking it should probably be deleted, but not wanting to make that decision alone. I think we can definitely use that first paragraph. And maybe some other parts too? Since we have the CoC, we can probably lose the flamewar part.
Right, much of that is pretty dated. Maybe something of use can still be made of some of it but I don't think it needs to live in the FAQ. If you need a place to move it, you could stick it on http://wiki.inkscape.org/wiki/index.php/OtherGoals. I've already got a todo to cleanup that page some day.
Hhmm....I'm thinking of an introduction to the Contribute page, which contains most of that info. Section title "So, You Want to Contribute to Inkscape? Here's how to get started" More warm and fuzzy, but maybe too corny?
C R, jump in with comments too :-)
Thanks! Sorry for the lengthy reply.
All best, brynn PS - another thought - Maybe the CoC could have some language for bringing new people in without saying "patches welcome"?
Nah, I'd guess by the time a reader got to the CoC they would have already seen enough of Inkscape to already feel appropriately welcome. :-)
Bryce
-----Original Message----- From: Bryce Harrington Sent: Sunday, January 22, 2017 7:51 PM To: brynn Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 22, 2017 at 08:50:49AM -0700, brynn 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.
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 :-)
I think that's a brilliant idea. You're right that we have written bits along these lines in the past, which could be extracted, dusted off, and polished to be more digestible to a more modern audience.
You're right that there's probably a few different "types" of people so maybe a few different pages to message in different ways would make sense. I.e. one that talks to people who could get into coding work might focus on explaining branches and patch contributions, whereas another page might come from the angle of someone who isn't AT ALL interested in coding and instead just address good non-coding ways to contribute. Another one geared for translators, another maybe for evangelists, yet another specifically focused on usability testing. Or something like that.
Would you like to take a shot at extracting the existing text and roughing it into a more useful shape? I think I could contribute verbage to the pages, or link in someone to help.
Bryce
On Sun, 2017-01-29 at 13:29 -0700, brynn wrote:
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
You can start documenting website development here:
https://gitlab.com/inkscape/inkscape-web/wikis/home
It's empty at the moment, but I imagine it'll be filled with all the documentation and thoughts about things on the website.
I'll be working to unpick any web related pages on the wiki so we can put them all together with the project's code.
Best Regards, Martin Owens
Hhmmm, I don't quite understand what you mean, Martin. Sometimes you skip a step in your comments or logic that I can't infer. I actually didn't understand what Bryce meant about closing the current wiki in favor of something else....if that's where your comments come from.
Or do you mean you want the current wiki page (http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development) moved over to the gitlab wiki?
Or do you mean to make notes in the gitlab wiki about these proposed changes (on Contribute and Promote pages)?
After 5 readings, I think you mean a little bit each of the last 2 guesses. But just for the record, can you clarify?
Thanks, brynn
-----Original Message----- From: Martin Owens Sent: Sunday, January 29, 2017 2:17 PM To: brynn ; Bryce Harrington Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] Website Development Was: User Involvement
On Sun, 2017-01-29 at 13:29 -0700, brynn wrote:
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
You can start documenting website development here:
https://gitlab.com/inkscape/inkscape-web/wikis/home
It's empty at the moment, but I imagine it'll be filled with all the documentation and thoughts about things on the website.
I'll be working to unpick any web related pages on the wiki so we can put them all together with the project's code.
Best Regards, Martin Owens
Sorry Brynn,
I mean to say: If you consider the inkscape-web project as it's own thing, then I want all documentation, all blueprints, all non-bug related notes to be in the gitlab wiki here:
https://gitlab.com/inkscape/inkscape-web/wikis/home
So the inkscape-web project will end up in two places. Deployed live on the web server and on GitLab. The plan is that no part of it will remain on Launchpad, no part of it will be on a media wiki and very little documentation will be committed to the repository itself (unlike inkscape itself in Bryce's plan)
Does this make better sense?
Best Regards, Martin Owens
On Sun, 2017-01-29 at 22:32 -0700, brynn wrote:
Hhmmm, I don't quite understand what you mean, Martin. Sometimes you skip a step in your comments or logic that I can't infer. I actually didn't understand what Bryce meant about closing the current wiki in favor of something else....if that's where your comments come from.
Or do you mean you want the current wiki page (http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development) moved over to the gitlab wiki?
Or do you mean to make notes in the gitlab wiki about these proposed changes (on Contribute and Promote pages)?
After 5 readings, I think you mean a little bit each of the last 2 guesses. But just for the record, can you clarify?
Hi Martin, Yes, I understand that. I just wasn't sure the things we're dicussing here need to be documented. If they need to be documented, I would probably just make a link to the list archive for this thread. I mean, based on past experience, we could even be discussing this off list. So you aren't suggesting a change such that we document this kind of discussion, right? But I am curious about no part of it remaining on Launchpad. You mean except for bug reports, right? Or will the inkscape-web bugs be moved over there too?
Thanks, brynn
-----Original Message----- From: Martin Owens Sent: Sunday, January 29, 2017 10:51 PM To: brynn ; Bryce Harrington Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] Website Development Was: User Involvement
Sorry Brynn,
I mean to say: If you consider the inkscape-web project as it's own thing, then I want all documentation, all blueprints, all non-bug related notes to be in the gitlab wiki here:
https://gitlab.com/inkscape/inkscape-web/wikis/home
So the inkscape-web project will end up in two places. Deployed live on the web server and on GitLab. The plan is that no part of it will remain on Launchpad, no part of it will be on a media wiki and very little documentation will be committed to the repository itself (unlike inkscape itself in Bryce's plan)
Does this make better sense?
Best Regards, Martin Owens
On Sun, 2017-01-29 at 22:32 -0700, brynn wrote:
Hhmmm, I don't quite understand what you mean, Martin. Sometimes you skip a step in your comments or logic that I can't infer. I actually didn't understand what Bryce meant about closing the current wiki in favor of something else....if that's where your comments come from.
Or do you mean you want the current wiki page (http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development) moved over to the gitlab wiki?
Or do you mean to make notes in the gitlab wiki about these proposed changes (on Contribute and Promote pages)?
After 5 readings, I think you mean a little bit each of the last 2 guesses. But just for the record, can you clarify?
On Tue, 2017-01-31 at 03:56 -0700, brynn wrote:
But I am curious about no part of it remaining on Launchpad. You mean except for bug reports, right? Or will the inkscape-web bugs be moved over there too?
Inkscape-web won't be on launchpad at all.
Martin,
On Tue, Jan 31, 2017 at 03:56:04AM -0700, brynn wrote:
Hi Martin, Yes, I understand that. I just wasn't sure the things we're dicussing here need to be documented. If they need to be documented, I would probably just make a link to the list archive for this thread. I mean, based on past experience, we could even be discussing this off list. So you aren't suggesting a change such that we document this kind of discussion, right?
Since it was one of my suggestions that spawned this thread, I should clarify better at what I was intending. What I had in mind is a landing page that explains the absolute basics:
1. Where do I find the inkscape_web source code? How do I check it out? (i.e. a pointer to the gitlab project + some basic setup hints)
2. Where do I find directions for setting up an inkscape_web instance on my local system? (i.e. a pointer to the docs in the source tree)
3. What help is needed? (i.e. pointer to a todo list)
4. Who can I talk to for proposing ideas, or getting help with problems? (i.e. a mailing list, IRC, etc.)
5. What is the process for getting changes accepted and landed?
6. When does the live website get updated? Is there a regular schedule?
Presumably this landing page would be in the inkscape_web wiki, but it could be whereever the inkscape_web team finds most convenient. Then, on the inkscape web proper we would include a link to that page on our Contribute page.
Hope that clears up what I had in mind here... And again, just a suggestion; if the inkscape_web team has ideas on how they want to handle new contributors, those would take priority.
Bryce
But I am curious about no part of it remaining on Launchpad.You mean except for bug reports, right? Or will the inkscape-web bugs be moved over there too?
Thanks, brynn
-----Original Message----- From: Martin Owens Sent: Sunday, January 29, 2017 10:51 PM To: brynn ; Bryce Harrington Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] Website Development Was: User Involvement
Sorry Brynn,
I mean to say: If you consider the inkscape-web project as it's own thing, then I want all documentation, all blueprints, all non-bug related notes to be in the gitlab wiki here:
https://gitlab.com/inkscape/inkscape-web/wikis/home
So the inkscape-web project will end up in two places. Deployed live on the web server and on GitLab. The plan is that no part of it will remain on Launchpad, no part of it will be on a media wiki and very little documentation will be committed to the repository itself (unlike inkscape itself in Bryce's plan)
Does this make better sense?
Best Regards, Martin Owens
On Sun, 2017-01-29 at 22:32 -0700, brynn wrote:
Hhmmm, I don't quite understand what you mean, Martin. Sometimes you skip a step in your comments or logic that I can't infer. I actually didn't understand what Bryce meant about closing the current wiki in favor of something else....if that's where your comments come from.
Or do you mean you want the current wiki page (http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development) moved over to the gitlab wiki?
Or do you mean to make notes in the gitlab wiki about these proposed changes (on Contribute and Promote pages)?
After 5 readings, I think you mean a little bit each of the last 2 guesses. But just for the record, can you clarify?
As long as I have time, I can make up very basic page with sections like that. And then other people can tweak in the details which I either get wrong or leave out.
All best, brynn
-----Original Message----- From: Bryce Harrington Sent: Tuesday, January 31, 2017 7:37 PM To: brynn Cc: Martin Owens ; C R ; inkscape-devel Subject: Re: [Inkscape-devel] Website Development Was: User Involvement
On Tue, Jan 31, 2017 at 03:56:04AM -0700, brynn wrote:
Hi Martin, Yes, I understand that. I just wasn't sure the things we're dicussing here need to be documented. If they need to be documented, I would probably just make a link to the list archive for this thread. I mean, based on past experience, we could even be discussing this off list. So you aren't suggesting a change such that we document this kind of discussion, right?
Since it was one of my suggestions that spawned this thread, I should clarify better at what I was intending. What I had in mind is a landing page that explains the absolute basics:
1. Where do I find the inkscape_web source code? How do I check it out? (i.e. a pointer to the gitlab project + some basic setup hints)
2. Where do I find directions for setting up an inkscape_web instance on my local system? (i.e. a pointer to the docs in the source tree)
3. What help is needed? (i.e. pointer to a todo list)
4. Who can I talk to for proposing ideas, or getting help with problems? (i.e. a mailing list, IRC, etc.)
5. What is the process for getting changes accepted and landed?
6. When does the live website get updated? Is there a regular schedule?
Presumably this landing page would be in the inkscape_web wiki, but it could be whereever the inkscape_web team finds most convenient. Then, on the inkscape web proper we would include a link to that page on our Contribute page.
Hope that clears up what I had in mind here... And again, just a suggestion; if the inkscape_web team has ideas on how they want to handle new contributors, those would take priority.
Bryce
But I am curious about no part of it remaining on Launchpad.You mean except for bug reports, right? Or will the inkscape-web bugs be moved over there too?
Thanks, brynn
-----Original Message----- From: Martin Owens Sent: Sunday, January 29, 2017 10:51 PM To: brynn ; Bryce Harrington Cc: C R ; inkscape-devel Subject: Re: [Inkscape-devel] Website Development Was: User Involvement
Sorry Brynn,
I mean to say: If you consider the inkscape-web project as it's own thing, then I want all documentation, all blueprints, all non-bug related notes to be in the gitlab wiki here:
https://gitlab.com/inkscape/inkscape-web/wikis/home
So the inkscape-web project will end up in two places. Deployed live on the web server and on GitLab. The plan is that no part of it will remain on Launchpad, no part of it will be on a media wiki and very little documentation will be committed to the repository itself (unlike inkscape itself in Bryce's plan)
Does this make better sense?
Best Regards, Martin Owens
On Sun, 2017-01-29 at 22:32 -0700, brynn wrote:
Hhmmm, I don't quite understand what you mean, Martin. Sometimes you skip a step in your comments or logic that I can't infer. I actually didn't understand what Bryce meant about closing the current wiki in favor of something else....if that's where your comments come from.
Or do you mean you want the current wiki page (http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development) moved over to the gitlab wiki?
Or do you mean to make notes in the gitlab wiki about these proposed changes (on Contribute and Promote pages)?
After 5 readings, I think you mean a little bit each of the last 2 guesses. But just for the record, can you clarify?
On Sun, Jan 29, 2017 at 01:29:31PM -0700, brynn wrote:
(Martin copied in, just fyi, no specific reply needed)
Sorry, fairly long reply (tldr for most readers)
Ditto, but I'll try and be brief in reply.
The sections look good. Would it make sense to reverse the order? ____________________
That's interesting thought. I seem to recall my first version of the page, the sections were reversed. I was thinking - list them from easiest to hardest, or things that take less skill, to things that take more skill.
But someone else said to have the coding stuff at the top, because that's what the project needs the most. I'm personally neutral on this, and I'm happy to make whatever changes are needed.
If you remember who that person was, might be worthwhile to loop them in on this discussion. (Heck, could have even been me!) It's certainly true coding is important but again we have the whole Develop top section devoted to it, so I really think we're ok on that count. Other things beyond coding are also critical to the project, and as most visitors to our site are probably non-coders I feel we really need to ensure we have an inviting-looking place for them, and I would worry leading with Coding might put them off.
(E.g. the opening sentence
of Contribute and Promote ought to be more engaging.)
I agree that would be a good idea, and I'll make a rough draft, maybe using the first paragraph of that last bit of info in the wiki (which I like). But C R has offered to make suggestions too. Should I just make working page, that we could all access and tweak on? I don't remember if C R is a website editor.
Sounds like a good starting point.
I really like the Community To-Do List page (contribute/to-do-list) and
I had hoped that this would be a useful page. But no one seems to be interested in those projects that are listed. Maybe because a lot of them need significant experience with the project.
I think that may be true. They did strike me as a bit advanced. I will try and help with ideas of more things we can include here. Bug me if I forget.
It's also likely people just aren't aware of the page, so once we flesh it out more it would be good to evangelize it a bit (more on this below).
I don't see "non-coding" as less important. When I read the title, I get excited, because here's something I could actually help with. It doesn't make me feel bad about myself, and I think my self-esteem is fairly intact.
*Grin* Fair enough!
But I understand that "non-" is a negative, and something more positive might be better. I just can't think of a good alternative. Suggestions? What's the opposite of coding or programming or hacking? "Other" would probably be too vague.
Yeah Other would be too vague, I almost suggested General but that's also vague. I suppose since I don't have any better ideas leave it as is and if I think of something later or someone else comes up with a brilliant idea, we can tackle it then. Maybe a differing perspective would give some better ideas.
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I've heard that term used in other FOSS projects and it has a nice ring to me.
I do think this is an important role in the project, one that I wish we had more people engaged on. Announcing releases would be a crucial duty here, and a number of the activities the Board is engaged in would work much better if we had a better organized team focusing on this.
As I've written previously, what makes FOSS projects like Inkscape successful is not vast userbases or lots of income - it's people like us contributing to the code and community in myriad ways both tangible and intangible. So a #1 purpose for an evangelism team would be contributor community building. Not necessarily like hard-sell 'recruitment' but more building connections between people and ensuring there are easily accessible on-ramps for people to join in.
A lot of things would fall under such a group, from establishing presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
The Helping Other Inkscape Users should be moved from the Promote page
to its own page.
That section is a little longer than Spread the Word, but still makes for a pretty short page, by itself. I guess I wouldn't have any objections. But if it could be expanded, would be better, imo. I just can't think of any other ways for helping other users.
Ok, seems sensible. It can always be broken out later if/when there's more content for it.
The Translations section looks fine.
Yes, I think Maren has tweaked that page to perfection. Unfortunately, I think she wants to take a break from website editing, except for translation-related things. I'll try to use it as a guide for the others. And if anyone else wants to help, of course let us know!
Understandable, and yes this would be a great area to bring in more people.
The Bugs section I think could be made more specific to just Review and
Verify Existing Bug Reports.
For the Bugs section, Testing, and Working with Code, I don't have the knowledge for making all the changes you described. I can move Report Bugs into the Testing section. But I can't make any of the other changes to Testing that you mentioned. I just don't have that knowledge.
Yes, totally understood. I mentioned it more because it is something that "needs to be on our collective todo list" and realize drafting something sensible will be a large project. I will try and work on it as I have time and keep an eye out for folks that could assist.
I can move Packaging to the top level Develop page, and delete the Write Extensions section, if you like. I don't follow your logic, but it's probably because I don't understand programming.
Sounds good.
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Right, exactly. I'm anticipating that Martin will have a place in mind to direct potential web developers to for orientation on website work, so am just suggesting we should point to that from here.
Thanks, Bryce
On Mon, 2017-01-30 at 11:19 -0800, Bryce Harrington wrote:
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Right, exactly. I'm anticipating that Martin will have a place in mind to direct potential web developers to for orientation on website work, so am just suggesting we should point to that from here.
Yes, all website documentation is on the gitlab inkscape-web wiki, there won't be a need for any exceptions as there's such a small amount of content and none for the user side that isn't the website itself anyway.
Thanks guys!
Best Regards, Martin Owens
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I'd avoid that particular word. It has negative connotations where I come from. I also quite dislike the idea that FLOSS is some sort of religion (which is a common meme), and the word "evangelism" has definite religious connections. People should understand this is not some cult, but rather a community project.
PS- will try and respond with some suggested text soon, but there's so much catching up to do in this conversation, I'm still trying to take it all in. :)
-C
On Mon, 2017-01-30 at 21:45 +0000, C R wrote:
How about "Evangelism"?
I'd avoid that particular word. It has negative connotations where I come from. I also quite dislike the idea that FLOSS is some sort of religion (which is a common meme), and the word "evangelism" has definite religious connections. People should understand this is not some cult, but rather a community project.
I prefer "Lollardism" such a better religious word.
I agree with CR, Evangelical has some negative connotations and we should be able to say "Zeal" without saying "Zealot"
Martin,
On Mon, Jan 30, 2017 at 09:46:20PM -0500, Martin Owens wrote:
On Mon, 2017-01-30 at 21:45 +0000, C R wrote:
How about "Evangelism"?
I'd avoid that particular word. It has negative connotations where I come from. I also quite dislike the idea that FLOSS is some sort of religion (which is a common meme), and the word "evangelism" has definite religious connections. People should understand this is not some cult, but rather a community project.
I prefer "Lollardism" such a better religious word.
I agree with CR, Evangelical has some negative connotations and we should be able to say "Zeal" without saying "Zealot"
Hrm, that really stinks, I like how "evangelize" sounds.
Well, then how about "advocacy"?
Bryce
Yes, I like "advocacy"! And Advocacy Team.
-----Original Message----- From: Bryce Harrington Sent: Monday, January 30, 2017 7:59 PM To: Martin Owens Cc: C R ; brynn ; inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Mon, Jan 30, 2017 at 09:46:20PM -0500, Martin Owens wrote:
On Mon, 2017-01-30 at 21:45 +0000, C R wrote:
How about "Evangelism"?
I'd avoid that particular word. It has negative connotations where I come from. I also quite dislike the idea that FLOSS is some sort of religion (which is a common meme), and the word "evangelism" has definite religious connections. People should understand this is not some cult, but rather a community project.
I prefer "Lollardism" such a better religious word.
I agree with CR, Evangelical has some negative connotations and we should be able to say "Zeal" without saying "Zealot"
Hrm, that really stinks, I like how "evangelize" sounds.
Well, then how about "advocacy"?
Bryce
PS- will try and respond with some suggested text soon, but there's so
much catching up to do in this conversation, I'm still trying to take it all in. :)
Sorry C R. When I see something I can actually help with, sometimes I jump right in. Take your time, no rush.
All best, brynn
-----Original Message----- From: C R Sent: Monday, January 30, 2017 2:45 PM To: Bryce Harrington Cc: brynn ; inkscape-devel ; Martin Owens Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I'd avoid that particular word. It has negative connotations where I come from. I also quite dislike the idea that FLOSS is some sort of religion (which is a common meme), and the word "evangelism" has definite religious connections. People should understand this is not some cult, but rather a community project.
PS- will try and respond with some suggested text soon, but there's so much catching up to do in this conversation, I'm still trying to take it all in. :)
-C
Sorry C R. When I see something I can actually help with, sometimes I jump right in. Take your time, no rush.
No need to be sorry. Just don't feel you have to hold back on my account. So many good ideas is simply worth the time to read through and consider. :) By all means, continue as you were.
-C
All best, brynn
-----Original Message----- From: C R Sent: Monday, January 30, 2017 2:45 PM To: Bryce Harrington Cc: brynn ; inkscape-devel ; Martin Owens
Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
I'm not sure if the Promote page might be ill-conceived or not. All
of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I'd avoid that particular word. It has negative connotations where I come from. I also quite dislike the idea that FLOSS is some sort of religion (which is a common meme), and the word "evangelism" has definite religious connections. People should understand this is not some cult, but rather a community project.
PS- will try and respond with some suggested text soon, but there's so much catching up to do in this conversation, I'm still trying to take it all in. :)
-C
How about "Evangelism"?
......
A lot of things would fall under such a group, from establishing
presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
Maybe we should add the creation of such a team, to the To-Do List page? It's yet another more advanced project. But listing it might help get the ball rolling. I mentioned recently about a possibility of a team for announcing releases, maybe something like a calling tree (except email). But I can see an Evangelism team which has that as one of its jobs.
It sounds like you might need to either lead that team, or be closely involved, at least until the team understands its role. Then it could fly on its own. Well, at least it's not a clear concept to me. I'd be glad to be part of such a team, but I couldn't lead it. Maybe that team could write up that page, and expand what's already there?
If you want to polish up a description, I'll add it to the To-Do List page. Or I could start with what you've already said, and you could tweak it directly on the website?
All best, brynn
-----Original Message----- From: Bryce Harrington Sent: Monday, January 30, 2017 12:19 PM To: brynn Cc: C R ; inkscape-devel ; Martin Owens Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 29, 2017 at 01:29:31PM -0700, brynn wrote:
(Martin copied in, just fyi, no specific reply needed)
Sorry, fairly long reply (tldr for most readers)
Ditto, but I'll try and be brief in reply.
The sections look good. Would it make sense to reverse the order? ____________________
That's interesting thought. I seem to recall my first version of the page, the sections were reversed. I was thinking - list them from easiest to hardest, or things that take less skill, to things that take more skill.
But someone else said to have the coding stuff at the top, because that's what the project needs the most. I'm personally neutral on this, and I'm happy to make whatever changes are needed.
If you remember who that person was, might be worthwhile to loop them in on this discussion. (Heck, could have even been me!) It's certainly true coding is important but again we have the whole Develop top section devoted to it, so I really think we're ok on that count. Other things beyond coding are also critical to the project, and as most visitors to our site are probably non-coders I feel we really need to ensure we have an inviting-looking place for them, and I would worry leading with Coding might put them off.
(E.g. the opening sentence
of Contribute and Promote ought to be more engaging.)
I agree that would be a good idea, and I'll make a rough draft, maybe using the first paragraph of that last bit of info in the wiki (which I like). But C R has offered to make suggestions too. Should I just make working page, that we could all access and tweak on? I don't remember if C R is a website editor.
Sounds like a good starting point.
I really like the Community To-Do List page (contribute/to-do-list) and
I had hoped that this would be a useful page. But no one seems to be interested in those projects that are listed. Maybe because a lot of them need significant experience with the project.
I think that may be true. They did strike me as a bit advanced. I will try and help with ideas of more things we can include here. Bug me if I forget.
It's also likely people just aren't aware of the page, so once we flesh it out more it would be good to evangelize it a bit (more on this below).
I don't see "non-coding" as less important. When I read the title, I get excited, because here's something I could actually help with. It doesn't make me feel bad about myself, and I think my self-esteem is fairly intact.
*Grin* Fair enough!
But I understand that "non-" is a negative, and something more positive might be better. I just can't think of a good alternative. Suggestions? What's the opposite of coding or programming or hacking? "Other" would probably be too vague.
Yeah Other would be too vague, I almost suggested General but that's also vague. I suppose since I don't have any better ideas leave it as is and if I think of something later or someone else comes up with a brilliant idea, we can tackle it then. Maybe a differing perspective would give some better ideas.
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I've heard that term used in other FOSS projects and it has a nice ring to me.
I do think this is an important role in the project, one that I wish we had more people engaged on. Announcing releases would be a crucial duty here, and a number of the activities the Board is engaged in would work much better if we had a better organized team focusing on this.
As I've written previously, what makes FOSS projects like Inkscape successful is not vast userbases or lots of income - it's people like us contributing to the code and community in myriad ways both tangible and intangible. So a #1 purpose for an evangelism team would be contributor community building. Not necessarily like hard-sell 'recruitment' but more building connections between people and ensuring there are easily accessible on-ramps for people to join in.
A lot of things would fall under such a group, from establishing presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
The Helping Other Inkscape Users should be moved from the Promote page
to its own page.
That section is a little longer than Spread the Word, but still makes for a pretty short page, by itself. I guess I wouldn't have any objections. But if it could be expanded, would be better, imo. I just can't think of any other ways for helping other users.
Ok, seems sensible. It can always be broken out later if/when there's more content for it.
The Translations section looks fine.
Yes, I think Maren has tweaked that page to perfection. Unfortunately, I think she wants to take a break from website editing, except for translation-related things. I'll try to use it as a guide for the others. And if anyone else wants to help, of course let us know!
Understandable, and yes this would be a great area to bring in more people.
The Bugs section I think could be made more specific to just Review and
Verify Existing Bug Reports.
For the Bugs section, Testing, and Working with Code, I don't have the knowledge for making all the changes you described. I can move Report Bugs into the Testing section. But I can't make any of the other changes to Testing that you mentioned. I just don't have that knowledge.
Yes, totally understood. I mentioned it more because it is something that "needs to be on our collective todo list" and realize drafting something sensible will be a large project. I will try and work on it as I have time and keep an eye out for folks that could assist.
I can move Packaging to the top level Develop page, and delete the Write Extensions section, if you like. I don't follow your logic, but it's probably because I don't understand programming.
Sounds good.
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Right, exactly. I'm anticipating that Martin will have a place in mind to direct potential web developers to for orientation on website work, so am just suggesting we should point to that from here.
Thanks, Bryce
On Tue, Jan 31, 2017 at 04:50:27AM -0700, brynn wrote:
How about "Evangelism"?
^D"Advocacy"
A lot of things would fall under such a group, from establishing
presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
Maybe we should add the creation of such a team, to the To-Do List page? It's yet another more advanced project. But listing it might help get the ball rolling.
Yes, I agree.
I will also put it on the agenda for the meeting Friday.
I mentioned recently about a possibility of a team for announcing releases, maybe something like a calling tree (except email). But I can see an Evangelism team which has that as one of its jobs.
It sounds like you might need to either lead that team, or be closely involved, at least until the team understands its role.
I can do that, for the short term anyway. Longer term I won't be able to give it adequate attention, so it should have its own lead.
Then it could fly on its own. Well, at least it's not a clear concept to me. I'd be glad to be part of such a team, but I couldn't lead it. Maybe that team could write up that page, and expand what's already there?
Yep. A lot will depend on the style of interests of the participants, so I expect the charter will need to evolve for a while as we go.
If you want to polish up a description, I'll add it to the To-Do List page. Or I could start with what you've already said, and you could tweak it directly on the website?
Yes, start with that.
The first order of business is going to revolve around recruitment. I suspect there's a lot of new community members looking to get involved that might be interested in being tapped. So could be merely a matter of locating them and asking. :-)
Bryce
All best, brynn
-----Original Message----- From: Bryce Harrington Sent: Monday, January 30, 2017 12:19 PM To: brynn Cc: C R ; inkscape-devel ; Martin Owens Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 29, 2017 at 01:29:31PM -0700, brynn wrote:
(Martin copied in, just fyi, no specific reply needed)
Sorry, fairly long reply (tldr for most readers)
Ditto, but I'll try and be brief in reply.
The sections look good. Would it make sense to reverse the order? ____________________
That's interesting thought. I seem to recall my first version of the page, the sections were reversed. I was thinking - list them from easiest to hardest, or things that take less skill, to things that take more skill.
But someone else said to have the coding stuff at the top, because that's what the project needs the most. I'm personally neutral on this, and I'm happy to make whatever changes are needed.
If you remember who that person was, might be worthwhile to loop them in on this discussion. (Heck, could have even been me!) It's certainly true coding is important but again we have the whole Develop top section devoted to it, so I really think we're ok on that count. Other things beyond coding are also critical to the project, and as most visitors to our site are probably non-coders I feel we really need to ensure we have an inviting-looking place for them, and I would worry leading with Coding might put them off.
(E.g. the opening sentence
of Contribute and Promote ought to be more engaging.)
I agree that would be a good idea, and I'll make a rough draft, maybe using the first paragraph of that last bit of info in the wiki (which I like). But C R has offered to make suggestions too. Should I just make working page, that we could all access and tweak on? I don't remember if C R is a website editor.
Sounds like a good starting point.
I really like the Community To-Do List page (contribute/to-do-list) and
I had hoped that this would be a useful page. But no one seems to be interested in those projects that are listed. Maybe because a lot of them need significant experience with the project.
I think that may be true. They did strike me as a bit advanced. I will try and help with ideas of more things we can include here. Bug me if I forget.
It's also likely people just aren't aware of the page, so once we flesh it out more it would be good to evangelize it a bit (more on this below).
I don't see "non-coding" as less important. When I read the title, I get excited, because here's something I could actually help with. It doesn't make me feel bad about myself, and I think my self-esteem is fairly intact.
*Grin* Fair enough!
But I understand that "non-" is a negative, and something more positive might be better. I just can't think of a good alternative. Suggestions? What's the opposite of coding or programming or hacking? "Other" would probably be too vague.
Yeah Other would be too vague, I almost suggested General but that's also vague. I suppose since I don't have any better ideas leave it as is and if I think of something later or someone else comes up with a brilliant idea, we can tackle it then. Maybe a differing perspective would give some better ideas.
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I've heard that term used in other FOSS projects and it has a nice ring to me.
I do think this is an important role in the project, one that I wish we had more people engaged on. Announcing releases would be a crucial duty here, and a number of the activities the Board is engaged in would work much better if we had a better organized team focusing on this.
As I've written previously, what makes FOSS projects like Inkscape successful is not vast userbases or lots of income - it's people like us contributing to the code and community in myriad ways both tangible and intangible. So a #1 purpose for an evangelism team would be contributor community building. Not necessarily like hard-sell 'recruitment' but more building connections between people and ensuring there are easily accessible on-ramps for people to join in.
A lot of things would fall under such a group, from establishing presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
The Helping Other Inkscape Users should be moved from the Promote page
to its own page.
That section is a little longer than Spread the Word, but still makes for a pretty short page, by itself. I guess I wouldn't have any objections. But if it could be expanded, would be better, imo. I just can't think of any other ways for helping other users.
Ok, seems sensible. It can always be broken out later if/when there's more content for it.
The Translations section looks fine.
Yes, I think Maren has tweaked that page to perfection. Unfortunately, I think she wants to take a break from website editing, except for translation-related things. I'll try to use it as a guide for the others. And if anyone else wants to help, of course let us know!
Understandable, and yes this would be a great area to bring in more people.
The Bugs section I think could be made more specific to just Review and
Verify Existing Bug Reports.
For the Bugs section, Testing, and Working with Code, I don't have the knowledge for making all the changes you described. I can move Report Bugs into the Testing section. But I can't make any of the other changes to Testing that you mentioned. I just don't have that knowledge.
Yes, totally understood. I mentioned it more because it is something that "needs to be on our collective todo list" and realize drafting something sensible will be a large project. I will try and work on it as I have time and keep an eye out for folks that could assist.
I can move Packaging to the top level Develop page, and delete the Write Extensions section, if you like. I don't follow your logic, but it's probably because I don't understand programming.
Sounds good.
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Right, exactly. I'm anticipating that Martin will have a place in mind to direct potential web developers to for orientation on website work, so am just suggesting we should point to that from here.
Thanks, Bryce
I couldn't find the exact message where I mentioned making a new item on the To-Do List page about an Advocacy Team leader. But this point in the discussion was pretty close.
So it's at the bottom of the list. Please feel free to tweak, or if you don't have website access, tell me what to change, and I will.
https://inkscape.org/en/contribute/to-do-list/?edit_off=true
All best, brynn
-----Original Message----- From: Bryce Harrington Sent: Monday, January 30, 2017 12:19 PM To: brynn Cc: C R ; inkscape-devel ; Martin Owens Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 29, 2017 at 01:29:31PM -0700, brynn wrote:
(Martin copied in, just fyi, no specific reply needed)
Sorry, fairly long reply (tldr for most readers)
Ditto, but I'll try and be brief in reply.
The sections look good. Would it make sense to reverse the order? ____________________
That's interesting thought. I seem to recall my first version of the page, the sections were reversed. I was thinking - list them from easiest to hardest, or things that take less skill, to things that take more skill.
But someone else said to have the coding stuff at the top, because that's what the project needs the most. I'm personally neutral on this, and I'm happy to make whatever changes are needed.
If you remember who that person was, might be worthwhile to loop them in on this discussion. (Heck, could have even been me!) It's certainly true coding is important but again we have the whole Develop top section devoted to it, so I really think we're ok on that count. Other things beyond coding are also critical to the project, and as most visitors to our site are probably non-coders I feel we really need to ensure we have an inviting-looking place for them, and I would worry leading with Coding might put them off.
(E.g. the opening sentence
of Contribute and Promote ought to be more engaging.)
I agree that would be a good idea, and I'll make a rough draft, maybe using the first paragraph of that last bit of info in the wiki (which I like). But C R has offered to make suggestions too. Should I just make working page, that we could all access and tweak on? I don't remember if C R is a website editor.
Sounds like a good starting point.
I really like the Community To-Do List page (contribute/to-do-list) and
I had hoped that this would be a useful page. But no one seems to be interested in those projects that are listed. Maybe because a lot of them need significant experience with the project.
I think that may be true. They did strike me as a bit advanced. I will try and help with ideas of more things we can include here. Bug me if I forget.
It's also likely people just aren't aware of the page, so once we flesh it out more it would be good to evangelize it a bit (more on this below).
I don't see "non-coding" as less important. When I read the title, I get excited, because here's something I could actually help with. It doesn't make me feel bad about myself, and I think my self-esteem is fairly intact.
*Grin* Fair enough!
But I understand that "non-" is a negative, and something more positive might be better. I just can't think of a good alternative. Suggestions? What's the opposite of coding or programming or hacking? "Other" would probably be too vague.
Yeah Other would be too vague, I almost suggested General but that's also vague. I suppose since I don't have any better ideas leave it as is and if I think of something later or someone else comes up with a brilliant idea, we can tackle it then. Maybe a differing perspective would give some better ideas.
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I've heard that term used in other FOSS projects and it has a nice ring to me.
I do think this is an important role in the project, one that I wish we had more people engaged on. Announcing releases would be a crucial duty here, and a number of the activities the Board is engaged in would work much better if we had a better organized team focusing on this.
As I've written previously, what makes FOSS projects like Inkscape successful is not vast userbases or lots of income - it's people like us contributing to the code and community in myriad ways both tangible and intangible. So a #1 purpose for an evangelism team would be contributor community building. Not necessarily like hard-sell 'recruitment' but more building connections between people and ensuring there are easily accessible on-ramps for people to join in.
A lot of things would fall under such a group, from establishing presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
The Helping Other Inkscape Users should be moved from the Promote page
to its own page.
That section is a little longer than Spread the Word, but still makes for a pretty short page, by itself. I guess I wouldn't have any objections. But if it could be expanded, would be better, imo. I just can't think of any other ways for helping other users.
Ok, seems sensible. It can always be broken out later if/when there's more content for it.
The Translations section looks fine.
Yes, I think Maren has tweaked that page to perfection. Unfortunately, I think she wants to take a break from website editing, except for translation-related things. I'll try to use it as a guide for the others. And if anyone else wants to help, of course let us know!
Understandable, and yes this would be a great area to bring in more people.
The Bugs section I think could be made more specific to just Review and
Verify Existing Bug Reports.
For the Bugs section, Testing, and Working with Code, I don't have the knowledge for making all the changes you described. I can move Report Bugs into the Testing section. But I can't make any of the other changes to Testing that you mentioned. I just don't have that knowledge.
Yes, totally understood. I mentioned it more because it is something that "needs to be on our collective todo list" and realize drafting something sensible will be a large project. I will try and work on it as I have time and keep an eye out for folks that could assist.
I can move Packaging to the top level Develop page, and delete the Write Extensions section, if you like. I don't follow your logic, but it's probably because I don't understand programming.
Sounds good.
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Right, exactly. I'm anticipating that Martin will have a place in mind to direct potential web developers to for orientation on website work, so am just suggesting we should point to that from here.
Thanks, Bryce
Nevermind, now deleted.
-----Original Message----- From: brynn Sent: Thursday, February 16, 2017 4:49 PM To: Bryce Harrington Cc: inkscape-devel Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Lineheightbug
I couldn't find the exact message where I mentioned making a new item on the To-Do List page about an Advocacy Team leader. But this point in the discussion was pretty close.
So it's at the bottom of the list. Please feel free to tweak, or if you don't have website access, tell me what to change, and I will.
https://inkscape.org/en/contribute/to-do-list/?edit_off=true
All best, brynn
-----Original Message----- From: Bryce Harrington Sent: Monday, January 30, 2017 12:19 PM To: brynn Cc: C R ; inkscape-devel ; Martin Owens Subject: Re: [Inkscape-devel] User Involvement Was: Post-Mortum: Line heightbug
On Sun, Jan 29, 2017 at 01:29:31PM -0700, brynn wrote:
(Martin copied in, just fyi, no specific reply needed)
Sorry, fairly long reply (tldr for most readers)
Ditto, but I'll try and be brief in reply.
The sections look good. Would it make sense to reverse the order? ____________________
That's interesting thought. I seem to recall my first version of the page, the sections were reversed. I was thinking - list them from easiest to hardest, or things that take less skill, to things that take more skill.
But someone else said to have the coding stuff at the top, because that's what the project needs the most. I'm personally neutral on this, and I'm happy to make whatever changes are needed.
If you remember who that person was, might be worthwhile to loop them in on this discussion. (Heck, could have even been me!) It's certainly true coding is important but again we have the whole Develop top section devoted to it, so I really think we're ok on that count. Other things beyond coding are also critical to the project, and as most visitors to our site are probably non-coders I feel we really need to ensure we have an inviting-looking place for them, and I would worry leading with Coding might put them off.
(E.g. the opening sentence
of Contribute and Promote ought to be more engaging.)
I agree that would be a good idea, and I'll make a rough draft, maybe using the first paragraph of that last bit of info in the wiki (which I like). But C R has offered to make suggestions too. Should I just make working page, that we could all access and tweak on? I don't remember if C R is a website editor.
Sounds like a good starting point.
I really like the Community To-Do List page (contribute/to-do-list) and
I had hoped that this would be a useful page. But no one seems to be interested in those projects that are listed. Maybe because a lot of them need significant experience with the project.
I think that may be true. They did strike me as a bit advanced. I will try and help with ideas of more things we can include here. Bug me if I forget.
It's also likely people just aren't aware of the page, so once we flesh it out more it would be good to evangelize it a bit (more on this below).
I don't see "non-coding" as less important. When I read the title, I get excited, because here's something I could actually help with. It doesn't make me feel bad about myself, and I think my self-esteem is fairly intact.
*Grin* Fair enough!
But I understand that "non-" is a negative, and something more positive might be better. I just can't think of a good alternative. Suggestions? What's the opposite of coding or programming or hacking? "Other" would probably be too vague.
Yeah Other would be too vague, I almost suggested General but that's also vague. I suppose since I don't have any better ideas leave it as is and if I think of something later or someone else comes up with a brilliant idea, we can tackle it then. Maybe a differing perspective would give some better ideas.
I'm not sure if the Promote page might be ill-conceived or not. All of it really contributes to the project (everything on both Contribute and Promote pages), but it's too much material for one page. And Promote was the best thing I could come up with for a page name. Open to suggestions.
How about "Evangelism"?
I've heard that term used in other FOSS projects and it has a nice ring to me.
I do think this is an important role in the project, one that I wish we had more people engaged on. Announcing releases would be a crucial duty here, and a number of the activities the Board is engaged in would work much better if we had a better organized team focusing on this.
As I've written previously, what makes FOSS projects like Inkscape successful is not vast userbases or lots of income - it's people like us contributing to the code and community in myriad ways both tangible and intangible. So a #1 purpose for an evangelism team would be contributor community building. Not necessarily like hard-sell 'recruitment' but more building connections between people and ensuring there are easily accessible on-ramps for people to join in.
A lot of things would fall under such a group, from establishing presence in software and artistic communities both online and off, sending reps and presenters to artist-focused events, arranging training opportunities (both user-focused and development-focused), writing, pushing news items on our site, and more.
The Helping Other Inkscape Users should be moved from the Promote page
to its own page.
That section is a little longer than Spread the Word, but still makes for a pretty short page, by itself. I guess I wouldn't have any objections. But if it could be expanded, would be better, imo. I just can't think of any other ways for helping other users.
Ok, seems sensible. It can always be broken out later if/when there's more content for it.
The Translations section looks fine.
Yes, I think Maren has tweaked that page to perfection. Unfortunately, I think she wants to take a break from website editing, except for translation-related things. I'll try to use it as a guide for the others. And if anyone else wants to help, of course let us know!
Understandable, and yes this would be a great area to bring in more people.
The Bugs section I think could be made more specific to just Review and
Verify Existing Bug Reports.
For the Bugs section, Testing, and Working with Code, I don't have the knowledge for making all the changes you described. I can move Report Bugs into the Testing section. But I can't make any of the other changes to Testing that you mentioned. I just don't have that knowledge.
Yes, totally understood. I mentioned it more because it is something that "needs to be on our collective todo list" and realize drafting something sensible will be a large project. I will try and work on it as I have time and keep an eye out for folks that could assist.
I can move Packaging to the top level Develop page, and delete the Write Extensions section, if you like. I don't follow your logic, but it's probably because I don't understand programming.
Sounds good.
Are you saying you want a page on the website, rather than a wiki page, for Website Development? I don't have the right kind of knowledge to be able to write such a page. All I could do is copy the wiki page over to the website. Glad to do it, but also welcome help in spicing it up.
Right, exactly. I'm anticipating that Martin will have a place in mind to direct potential web developers to for orientation on website work, so am just suggesting we should point to that from here.
Thanks, 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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 <cajhne@...400...>:
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" <bryce@...961... mailto:bryce@...961...> 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 Inkscape-devel@lists.sourceforge.net mailto:Inkscape-devel%40lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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" <Eduard.Braun2@...173...> 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 <cajhne@...400...> <cajhne@...400...>:
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" <bryce@...961...> 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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]
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
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
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
On Sun, Jan 22, 2017 at 10:41:03AM -0500, Martin Owens wrote:
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.
Thinking back through the history of the project, this reminds me of a recurring pattern we'd noticed. We introduce a feature that enables some use case that hadn't registered with us previously, but there is some problem limiting it and we get complaints about how broken that is. Then, the next release, we put more attention into that item and resolve the issues, but now some other new use case has been enabled as a result and it's got its own set of bugs.
For example, when we first introduced save as PDF, we figured it'd be a nice new output format for folks. But we had no idea how much pent up demand there was for it, and were rather taken aback at the level of complaints about missing features, bugs, and so on. With a few simple additions we'd opened the door for use cases we hadn't imagined, and found ourselves being roasted because our solution was so limited.
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".
Jeez, no this goes entirely the wrong direction for a solution. What this leads to is fatal gridlock in the release process. We would never be able to actually release.
I will spare you the full detailed rant on this (unless you want it), who wants to read a wall of text, right? Suffice it to say we have GOT to make the release process *easier* not harder, and to do that we need to work harder at minimizing the number of blocker bugs we deal with.
"Release early, release often." A few bugs will get through, maybe bad ones, but just keep releasing. The more releases we do and the less time we permit between them, the better the process will go. Less time between releases means fewer features per release, which means fewer new bugs added. More releases means more opportunities for end users to test and give feedback. More releases mean more PR opportunities, more chances to pull in more community members.
If you wish to indulge me in a bit of ranting I can give you a more elaborated answer with historical anecdotes and so on, but the short summary would be something like "blocker bug lists are harmful". IOW, the old adage "Perfect is the enemy of good" applies.
Bryce
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.
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?
This particular issue is of a class caused by re-engineering of the codebase. Ultimately this traces back to the dpi switch that we knew we needed to do in order to match the CSS standard. I think we may have even postponed it a release or two due to fear it would disrupt users.
Flipping the y-coordinate system is probably another change of this class. Multi-page support might be another. I'm sure there's tons more I'm just not thinking of. Even the gtk3 switch (which ideally shouldn't affect documents just usability) has some potential for similar scale disruptions.
The fundamental change for these kind of efforts is often relatively small, but they can often necessitate widespread changes throughout the codebase. Sometimes those places aren't obvious and are found only with intense testing. Because of this invasiveness, doing the change in a branch can be quite challenging - first, because as trunk's code evolves in parallel the branch has to keep getting rebased (or sometimes even rewritten) to follow suit; second, because branches tend to get little to no attention from the regular userbase. For both these reasons, there is a very strong motivation to land the changes in trunk as early as possible.
Unfortunately, a consequence is that you have to be *extremely* thorough in testing and stabilizing the change before release. Sometimes the required changes are beyond the scope of the original programmer - e.g. adjustments needed for platform specific needs, or measures required to ensure backwards compatibility or interoperability. Predicting these ahead of time may be next to impossible; finding someone with time and the right set of skills to fill in the remaining work can likewise be prohibitively challenging in a volunteer project like ours.
I know that users don't understand or care about any of these internal development details, many will just see it as wanton disregard for compatibility.
I don't have better ideas on how to handle these, that doesn't risk these (as someone said) "soul-crushing reviews" like that peppercarrot one. Traditionally we've just avoided making releases, sometimes for years at a time, until we're 100% sure every last glitch is ironed out, but that has numerous severe drawbacks and I more favor the opposite approach of very frequent releases.
However, fast releases don't give much time for thorough testing before release, relying instead on the "many eyeballs make bugs shallow" social-contract of open source. I know this may be expecting more than some of our current userbase is willing to tolerate, but in some ways a smaller but more actively involved userbase would be healthier for the project's longer term prospects as a community resource.
Bryce
participants (9)
-
Bryce Harrington -
brynn -
C R -
Eduard Braun -
Marc Jeanmougin -
Maren Hachmann -
Martin Owens -
Miguel Lopez -
Terry Brown