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...> 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@...1784...sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel