5 ms·

I don't maintain anything as big as Redis, but I've faced many similar problems all the same and I think I have an approach which makes it palatable. I wrote ab

I don't maintain anything as big as Redis, but I've faced many similar problems all the same and I think I have an approach which makes it palatable. I wrote about my approach at length here: https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-projects.html https://drewdevault.com/2018/06/01/How-I-maintain-FOSS-proje... But the main thing is that almost all bug reports, feature requests, and so on, get sent to /dev/null. Users who care about a problem are expected to work on that problem themselves. In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well. Then I focus only on helping new contributors get their bearings and making regular contributors happy and comfortable with their work on the project. So far this approach has been very successful for me - I don't get burned out, and neither do my contributors, and we have happy, healthy communities where people work at a pace which suits them best and aren't stressed or overwhelmed. Sure, lots of feature requests and bug reports get neglected, but I think the net result is still a very positive impact on the project. The occasional drive-by bug submitter provides far less value to the project as someone who writes even one patch. Focusing on keeping the people who create the most value happy makes for a more productive project and a better end result. Some people are put out by the fact that their bug report, feature request, etc goes unanswered, but I can quickly put the guilt out of my mind by reminding myself that ignoring them is doing a benefit to the project. And in practice, I generally have time to give people some words of encouragement and a nudge in the right direction towards writing a patch without burning myself out.

tda 7y ago
I found the writings of Peter Hintjens (creator of ZeroMQ) very inspiring, where he describes the merits of Optimistic merging (OM). Quoting at length from http://hintjens.com/blog:106 http://hintjens.com/blog:106: Standard practice (Pessimistic Merging, or PM) is to wait until CI is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as "I don't like how you do this" or "this doesn't fit with our project vision." In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation. PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates: It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse. It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will. It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die. It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move. It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors. It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone. Now let's see how this works when we use Optimistic Merge. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects: Good contributors who know the rules and write excellent, perfect patches. Good contributors who make mistakes, and who write useful yet broken patches. Mediocre contributors who make patches that no-one notices or cares about. Trollish contributors who ignore the rules, and who write toxic patches. PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2). Let's see how each scenario works, with PM and OM: PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project. PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted. PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever. In each case, OM has a better outcome than PM. In the majority case (patches that need further work), Optimistic Merge creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on.
- majewsky 7y ago
  Broken quotes reformatted for readability: ---- > It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse. > It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will. > It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die. > It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move. > It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors. > It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone. ---- > Good contributors who know the rules and write excellent, perfect patches. > Good contributors who make mistakes, and who write useful yet broken patches. > Mediocre contributors who make patches that no-one notices or cares about. > Trollish contributors who ignore the rules, and who write toxic patches. ---- > PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project. > PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. > PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted. > PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.
outime 7y ago
>In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well. There are a good bunch of people who have never written any C and even more people who have no idea about the internals of Redis, yet they are Redis users and they do find bugs. I wouldn't expect those users to write a patch for every bug they find to be honest.
- Crinus 7y ago
  I think the idea is that given enough users, the bugs who will be encountered by non-fixers will also be encountered by fixers so they'll be fixed, otherwise they are so rare as to not be worth the effort of wasting time with useless non-fixer reports to find the useful non-fixer ones. I'm not sure how i feel about that TBH, personally i'd like to know about bugs even if they do not come with patches but at the same time i understand not wanting to be bothered by wading through useless reports. Perhaps there should be end user oriented bugtrackers that look more similar to something like a hybrid between a forum and a reddit/HN post with voting (no downvotes though, kinda like GOG's wishlists) so that developers will have a rough idea where to focus next and "locked" (but perhaps visible, at least for FOSS projects) traditional bugtrackers where end user entries migrate (and linked to) once developers decide that this will be worked on. It wont solve all issues, especially with people potentially going "why aren't you fixing that bug-but-really-a-feature-that-requires-rearchitecting-the-entire-thing that has 897482959204 votes and instead work on whatever-else that Nobody Asked For(tm)?", but i guess you can't fix entitlement with technical means.
  - gtirloni 7y ago
    All properly filled bug reports are useful. This mentality that only writing code matters needs to stop. Open source projects (or any project for that matter) is way more than just writing code and the people doing the "other" work need to be recognized and encouraged to continuing that. The lack of such people is exactly the major cause of burnout from maintainers who just want to code. Not replying to all your points directly, just making a general statement about this whole thread.
alias_neo 7y ago
I'm interested in your approach here because I generally disagree with ignoring bug submissions from "drive-by"s. As a developer, I might have the time to investigate and submit a bug for your code, but at the end of the day, is probably just one more bug in 100 other pieces of code preventing me from writing the code I need to. Getting familiar with the code of a project you're using, to the extent that your can submit a reasonable PR is a not-insignificant time dedication. I've found a variety of attitudes from upstream code I've reported to, ranging from "you're wrong" to the bug being fixed and pushed to master within an hour. I've formed an opinion, amongst the projects I work with, about whom I should give more of my (professional) time to, that usually begins with how receptive they are to a perfectly good bug report which I don't have the (professional) time to fix. The ones that have proven "pleasant" to work with have made it much easier for me to convince my bosses that their money is well spent giving back.
MakeUsersWant 7y ago
So that is why so many OSS projects are full of bugs and horrible usability. In the past, I have tried to help with clear, reproducible bug reports. Quite often I spent an hour tracking down a bug, writing up why it matters, and then got ignored or dismissed. Those OSS projects that deliver a quality product, also took my bug reports seriously (and sometimes disagreed).
- Crinus 7y ago
  > So that is why so many OSS projects are full of bugs and horrible usability. Possibly, but not necessarily. What is certain is that no developer who gives you free stuff has any obligation to fix bugs nor to submit themselves to any low-key bullying from users of said free stuff about how to spend their time and develop the software they decide to share with others.
  - IggleSniggle 7y ago
    I agree! But let’s not discount the value being provided by bug reporters who give a superb description and excellent reproducibility. They just wrote a codeable test case, which is valuable free stuff, ie like for like.
  - StaticRedux 7y ago
    TL;DR; FOSS Zeolots: everyone should use FOSS! Micro$oft is evil! Also FOSS Zeolots: Oh you have a bug? Screw you. You're getting it for free. Stop complaining. I'm busy making a new icon. OSS is great. But until this attitude is killed, it will continue to hover just above "who gives a shit" for anything other than developers
    - Crinus 7y ago
      FWIW i am not a FOSS zealot. If anything some of the software i find enjoyable to use is not FOSS (but sadly a lot of it is older software, largely because of user hostile modern trends - see Electron, phone-home DRM, adware, etc - but also because newer versions or alternatives simply have worse UX and/or bloated to almost unusability) and really my comments come more from a "you are entitled to what you pay for" stance.
deleted 7y ago
[deleted]

tda 7y ago

I found the writings of Peter Hintjens (creator of ZeroMQ) very inspiring, where he describes the merits of Optimistic merging (OM). Quoting at length from http://hintjens.com/blog:106 http://hintjens.com/blog:106: Standard practice (Pessimistic Merging, or PM) is to wait until CI is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as "I don't like how you do this" or "this doesn't fit with our project vision." In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation. PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates: It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse. It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will. It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die. It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move. It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors. It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone. Now let's see how this works when we use Optimistic Merge. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects: Good contributors who know the rules and write excellent, perfect patches. Good contributors who make mistakes, and who write useful yet broken patches. Mediocre contributors who make patches that no-one notices or cares about. Trollish contributors who ignore the rules, and who write toxic patches. PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2). Let's see how each scenario works, with PM and OM: PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project. PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted. PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever. In each case, OM has a better outcome than PM. In the majority case (patches that need further work), Optimistic Merge creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on.

majewsky 7y ago
Broken quotes reformatted for readability: ---- > It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse. > It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will. > It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die. > It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move. > It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors. > It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone. ---- > Good contributors who know the rules and write excellent, perfect patches. > Good contributors who make mistakes, and who write useful yet broken patches. > Mediocre contributors who make patches that no-one notices or cares about. > Trollish contributors who ignore the rules, and who write toxic patches. ---- > PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project. > PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project. > PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted. > PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.

outime 7y ago

>In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well. There are a good bunch of people who have never written any C and even more people who have no idea about the internals of Redis, yet they are Redis users and they do find bugs. I wouldn't expect those users to write a patch for every bug they find to be honest.

Crinus 7y ago
I think the idea is that given enough users, the bugs who will be encountered by non-fixers will also be encountered by fixers so they'll be fixed, otherwise they are so rare as to not be worth the effort of wasting time with useless non-fixer reports to find the useful non-fixer ones. I'm not sure how i feel about that TBH, personally i'd like to know about bugs even if they do not come with patches but at the same time i understand not wanting to be bothered by wading through useless reports. Perhaps there should be end user oriented bugtrackers that look more similar to something like a hybrid between a forum and a reddit/HN post with voting (no downvotes though, kinda like GOG's wishlists) so that developers will have a rough idea where to focus next and "locked" (but perhaps visible, at least for FOSS projects) traditional bugtrackers where end user entries migrate (and linked to) once developers decide that this will be worked on. It wont solve all issues, especially with people potentially going "why aren't you fixing that bug-but-really-a-feature-that-requires-rearchitecting-the-entire-thing that has 897482959204 votes and instead work on whatever-else that Nobody Asked For(tm)?", but i guess you can't fix entitlement with technical means.
- gtirloni 7y ago
  All properly filled bug reports are useful. This mentality that only writing code matters needs to stop. Open source projects (or any project for that matter) is way more than just writing code and the people doing the "other" work need to be recognized and encouraged to continuing that. The lack of such people is exactly the major cause of burnout from maintainers who just want to code. Not replying to all your points directly, just making a general statement about this whole thread.

alias_neo 7y ago

I'm interested in your approach here because I generally disagree with ignoring bug submissions from "drive-by"s. As a developer, I might have the time to investigate and submit a bug for your code, but at the end of the day, is probably just one more bug in 100 other pieces of code preventing me from writing the code I need to. Getting familiar with the code of a project you're using, to the extent that your can submit a reasonable PR is a not-insignificant time dedication. I've found a variety of attitudes from upstream code I've reported to, ranging from "you're wrong" to the bug being fixed and pushed to master within an hour. I've formed an opinion, amongst the projects I work with, about whom I should give more of my (professional) time to, that usually begins with how receptive they are to a perfectly good bug report which I don't have the (professional) time to fix. The ones that have proven "pleasant" to work with have made it much easier for me to convince my bosses that their money is well spent giving back.

MakeUsersWant 7y ago

So that is why so many OSS projects are full of bugs and horrible usability. In the past, I have tried to help with clear, reproducible bug reports. Quite often I spent an hour tracking down a bug, writing up why it matters, and then got ignored or dismissed. Those OSS projects that deliver a quality product, also took my bug reports seriously (and sometimes disagreed).

Crinus 7y ago
> So that is why so many OSS projects are full of bugs and horrible usability. Possibly, but not necessarily. What is certain is that no developer who gives you free stuff has any obligation to fix bugs nor to submit themselves to any low-key bullying from users of said free stuff about how to spend their time and develop the software they decide to share with others.
- IggleSniggle 7y ago
  I agree! But let’s not discount the value being provided by bug reporters who give a superb description and excellent reproducibility. They just wrote a codeable test case, which is valuable free stuff, ie like for like.
- StaticRedux 7y ago
  TL;DR; FOSS Zeolots: everyone should use FOSS! Micro$oft is evil! Also FOSS Zeolots: Oh you have a bug? Screw you. You're getting it for free. Stop complaining. I'm busy making a new icon. OSS is great. But until this attitude is killed, it will continue to hover just above "who gives a shit" for anything other than developers
  - Crinus 7y ago
    FWIW i am not a FOSS zealot. If anything some of the software i find enjoyable to use is not FOSS (but sadly a lot of it is older software, largely because of user hostile modern trends - see Electron, phone-home DRM, adware, etc - but also because newer versions or alternatives simply have worse UX and/or bloated to almost unusability) and really my comments come more from a "you are entitled to what you pay for" stance.

deleted 7y ago

[deleted]