Add code of conduct

[rmarquis]

In line with the refactoring effort (#443) and because GitHub encourages to implement proper open source guidelines: add Code of conduct.

This is a bit tricky to address since pacaur development is voluntarily not very friendly due to some spoon feeding abuse in the past, but this is something that should eventually be addressed.

Due to the personal initial objectives of this project (making the AUR faster to use for myself), the entry barrier to the AUR is also considerably lowered for newbies, which sometimes don't want to take further responsibility for themselves. At some point, the noise ratio of help vampires vs useful reports was so high that several steps were taken to reduce it to a sustainable level, including:

• making it clear in man page that people should know at least the basics
• making it clear on the AUR comments page and GH wiki that I'll not deal with incompetence
• making it clear that my free time isn't a freebee to grab
• adding a template automatically displayed when opening new issues on the tracker
• adopting a zero policy towards disrespectful people on GH in the form of bans (the last one not too long ago)

All of the above considerably decreased the amount of crap I had to deal with, but I reckon this isn't without consequences:

• contributors might have to deal with some hostility from my side
• I tend to be automatically more on the rejection side of new ideas/proposals, which isn't constructive (especially when I misunderstoop the original proposal, or when I'm simply plain wrong)

Having a proper code of conduct and enforcing it can help to facilitate a healther environment for potential contributors, while still keeping the noise ratio as low as possible.

Suggestions welcome here.

[ismaelgv]

This is really necessary for a sane project to growth. Rules and statements should be clear and concise but I think that being harsh is not needed. I totally understand your position and some people attitude that burns you a lot.

Some ideas to add to the code of conduct and even issue template:

• Offer a link for support questions to the forum or IRC channel.
• Politely inform that this program is for experienced users and show a link of makepkg wiki page.
• Ask for money in a clear way, a link to you paypal account. Even better, create a Bountysource for the project. In my experience, it works pretty well to attract contributors, to give money to specific issue/feature request or to motivate people in general. You could also try a Patreon but I think Bountysource will work pretty nice for this kind of project.

[rmarquis]

Rules and statements should be clear and concise but I think that being harsh is not needed. I totally understand your position and some people attitude that burns you a lot.

Yet being harsh proved to be very effective against help vampires and other unreasonable requests. Here I'm more concerned about limiting the downside for knowledgeable contributors than being "nice" to everyone. This said, I'm all for a clear, fair but strictly enforced code of conduct.

And for everyone reading this: with due respect, "thinking that being harsh is not needed" has no value to me, since this little personal project that gained so much popularity made me experience the harsh reality of people taking free code for granted without any respect whatsoever. If anything, this project made me gain more respect for programmers and bitterness for users themselves.

Ask for money in a clear way, a link to you paypal account.

Just to clarify: asking for money is only about keeping people disrespecting my free time away. This started as a small personal project which has never been about making money of it.

I've only set up a Paypal link after a few requests, and with that in mind, I believe the link in man page is visible enough to possible donators (for those interested, total amount received to this day is about USD $50 from 4 donators - I now empirically know that at least 4 people have read the man page entirely 👍). With that amount involved, I believe bounty source won't work, and I am not sure I want it to work anyway.

I've also set up a gratipay account some time ago, but more because I'm interested in the system itself rather than I expect receiving money from it.

[ismaelgv]

Yet being harsh proved to be very effective against help vampires and other unreasonable requests. Here I'm more concerned about limiting the downside for knowledgeable contributors than being "nice" to everyone. This said, I'm all for a clear, fair but stricly enforced code of conduct.

I don't think you got to be 'nice' to everybody but being harsh actually has many downsides. In my opinion, this attitude effectively makes help vampires and unreasonable requests go away but also possible contributors and some people that are willing to report a bug but they are not very sure what is happening under the hood (related to pacaur not makepkg). I strongly believe that stupid people are usually very noisy, most of users are reasonable if you explain them politely what they are doing wrong. Just put the info in the issue template (without yelling at people, lol): support -> link to IRC, link to the forums, link to the wiki, link to Paypal. In the case people are still retarded and open an invalid issue: close the issue and answer with clear premade answers, you can even store them in the saved reply menu of GitHub.

We agree that the code of conduct must be clear, fair and strictly applied. I just see that a different way to apply it can make people/community more inclined to contribute to the project.

Just to clarify: asking for money is only about keeping people disrespecting my free time away. This started as a small personal project which has never been about making money of it.

I am aware of this fact. My proposal to show Paypal link/Bountysource on the template was on this way, you can make pretty clear that if anybody is demanding support they can pay for it in just a click.

Other solution to all these problems could be creating a fake dummy helper (noobaur) to attract basic users issues and requests and keep pacaur issue tracker clean. 😆

[rmarquis]

I don't think you got to be 'nice' to everybody but being harsh actually has many downsides.

Yes, this is the topic of this ticket. This is a matter of implementation.

I strongly believe that stupid people are usually very noisy, most of users are reasonable if you explain them politely what they are doing wrong.

In many case, users don't take time to inform themselves. I don't want to "politely explain them" again and again what they can read in the man page.

Just put the info in the issue template (without yelling at people, lol): support -> link to IRC, link to the forums, link to the wiki, link to Paypal.

I guess this is where we disagree: having a community available doesn't mean we should rely on it to provide support for vampires. This is especially bad when the community in question targets a technical, DIY userbase. While this isn't entirely depending on our control, I really don't want to encourage this behavior.

In the case people are still retarded and open an invalid issue: close the issue and answer with clear premade answers, you can even store them in the saved reply menu of GitHub.

I didn't know about premade answer - this might be very useful in the future.

I am aware of this fact. My proposal to show Paypal link/Bountysource on the template was on this way, you can make pretty clear that if anybody is demanding support they can pay for it in just a click.

I might not be having expressed my view clearly enough here: I don't want people to pay. I don't want them to bother me with questions they can easily find answers to in the man page. Either I should put a minimum price tag of $200 pop a question to avoid all questions, or let them find the Paypal link in the man page they'll have to read.

Other solution to all these problems could be creating a fake dummy helper (noobaur) to attract basic users issues and requests and keep pacaur issue tracker clean. 😆

Yes, technically having another popular helper is probably the easiest way to avoid all of these issues - but that isn't something you create of thin air, or choose to become. :)

Lastly, thank for your input. My answer might not be perceived as entirely receptive, but as said above this is a tricky subject.

[ismaelgv]

I guess this is where we disagree: having a community available doesn't mean we should rely on it to provide support for vampires. This is especially bad when the community in question targets a technical, DIY userbase. While this isn't entirely depending on our control, I really don't want to encourage this behavior.

You are right, it seems fair to me.

Lastly, thank for your input. My answer might not be perceived as entirely receptive, but as said above this is a tricky subject.

Don't you worry, I prefer clear and blunt communication. In general, I feel that lowering a bit the tone could be positive but this is just me trying to give an opinion from a different and maybe a bit 'naive' perspective. I fully understand your point and that you have very valid reasons to manage this project that way.

[AladW]

Once you've reached the stage of being "popular", keeping a healthy community becomes IMO a very complex problem. In Arch, we have the benefit of a comparatively involved installation process and a zero-tolerance policy on supporting derivative works, which takes away the burden of help vampires from the community and puts it on the derivates. With pacaur, you obviously only have one "product" which is used on anything with access to the AUR, including the derivates.

For aurutils, I've achieved a ~0% noise ratio by adhering to two simple principles:

1. Only advertise the software where users that are likely to contribute are active, in particular the Arch Forums and Wiki. In particular, avoid "popular" channels such as Reddit or IRC.
2. Leave out the last few layers of abstraction so that reading at least one man page is mandatory.

Achieving point 2 might be possible with pacaur 5, e.g. if using a local repo as described in #643. Point 1 is too late for this project as pointed out. For the current state of things, I would agree to use premade answers, but I would additionally lock any "invalid" issue to collaborators after closing it to avoid unnecessary bikeshed. This policy is similar to the "Dustbin" approach used on the Arch Linux forums.

A more radical alternative would be to close the Issue tracker on github and use a moderated system for tracking bugs, e.g. a mailing list. The traffic could be then be routed to a separate email address or an IMAP filter.

[rmarquis]

Point 1 is obviously too late for this project.

Popularity was also completely out of my control. As said above, you don't "choose" to become popular. Pacaur has barely been advertized by myself before users start advertizing it. Once you have a single satisfied user, it is too late. This phenomena is also becoming visible on the irc channel for aurutils, but here 2/ kicks in.

There has been quite a move (mostly from yaourt users) to pacaur when the wiki table has been added, but it only reinforced its already existing popularity.

I also believe the AUR popularity counter on the AUR page played a big role. Once the package reaches the first page and top ranks, there is a positive feedback loop created. Popular packages are most visible, and more voted on, and as a consequence become even more popular.

Derivatives also play a role, but I'm not sure to what extend this applies to pacaur. The most popular derivative sticks to yaourt because its main devs prefer it strongly. But I think it is installed by default on the lesser known Bridge Linux.

but I would additionally lock any "invalid" issue to collaborators after closing it to avoid unnecessary bikeshed.

I'm not differentiating the various Invalid issues just to keep it simply to myself (Invalid only means I don't need to look at them anymore). Historically, some people commented on issues I closed as Invalid because I misunderstood the issue reported or was wrong on my approach, and I subsequently reopened them, so this isn't the correct approach either - I do however simply ban people that display behavior that doesn't deserve my time.

A more radical alternative would be to close the Issue tracker on github

Not an option for me. I use github because it simplifies my workflow, I don't want to handle yet another infrastructure for so little benefits, and losing all the benefits of GH too.