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