6 ms·

Understanding user support systems in open source

48 points by ryanar 8y ago

whatupmd 8y ago
For the "Issue Triage" analysis I would say lines_added,lines_remove,commits,number_issues_involved_in would be interesting to see as well. For example caphrim007 is number 5 in commits over that period but added 5x as many lines of code as next closest committer. However, the code maybe against a new under-used feature so the actual end-user usage could be low. It would also be interesting to juxtapose top committers commit graphs against issue assignment and resolution timeline. When does issue triage by top committers wax and wane? Do big commits (new features) overlap with issue assignment/resolution dates? Does high volume issue assignment/resolution follow big commits?
mlthoughts2018 8y ago
Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. Most of the dysfunction I see in open source projects that take an ambivalent attitude towards the bug fixes and urgent feature needs of long-term users seems based in pure ego. Core devs want to keep being the leading edge designers and implementers of the project and are extremely stingy about letting new or intermediate contributors to the project bring fresh perspective and excitement into big new feature implementation or refactoring. You can make a lot of disingenuous arguments that this is to protect the style and design approach of the original core, but it’s not. It’s just ego. Look, people are obviously free to say if they are dedicating their free time to some open source project, then they only want to work on the aspects of it they like or the aspects that might seem glamorous in a blog post or conference presentation or whatever. Being “allowed” to take that attitude is pretty much inconsequential though. If you do that, your project is entering one of two modes: death mode where new developers realize you will only permit them to work on gruntwork and you lose any capacity to actually fix things because nobody joins your project, or North Korea mode like the linux kernel where some crazed monarch or oligarchs use intimidation and public shaming as primary code review techniques. If you are a really smart core dev of open source, stop working on the big new features. I know it hurts your ego to let your baby into the hands of newbies. Instead, do more code review, tutorials, answers on SO, and go way out of your way to make new contributors feel like you are impressed with their skill, that you want to pair with them through meaningful PRs right away, no “good first task” grunt work ego crap.
- thrower123 8y ago
  > Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. At this point you need management and support staff. Trying to pound square peg developers into those round holes is rather hopeless, especially when it is free work not paid.
  - mlthoughts2018 8y ago
    Sure, I agree it’s still logistically challenging. I’m just claiming the hard part is the ideological hurdle of getting the original core devs of the project to willingly facilitate frequent “changing of the guard” where the burden of critical new features and design is wholeheartedly given to new and intermediate developers of the project, to graciously let other people take the reins and have the core devs with an attitude of service to their community of users, fixing bugs, adding small feature enhancements, and particularly creating excellent documentation and tutorials. That’s the first step. Templates, disqus boards, SO, etc., aren’t going to save you if the core devs view the open source project as a walled garden where they pick and choose what to work on based on a need to “be the one” who is responsible for milestones of implementation.
    - thrower123 8y ago
      What's the incentive to those developers to take on this pain-in-the-ass corporate kind of work, rather than just doing the work that they enjoy that made the project noticeable in the first place? Nothing is owed to anybody, if it's being made into unpleasant management work, you can just pick up your ball and go home and do something else. I'm not really sure I want new developers doing core work on a project, and would be somewhat skeptical of projects that did adopt such practices without heavy oversight.
      - mlthoughts2018 8y ago
        The incentive is just if they want the project to survive and thrive and continue. They may not want this, or may value their pleasure of hacking on it higher than long-term liveness. I’m not making any normative judgments about _whether_ they want one set of preferences or the other, only commenting that it turns out (normatively) badly, from the perspective of the community around the project, if they don’t prioritize the overall liveness of the project (which comes at the cost of “doing as they please”).
Sir_Cmpwn 8y ago
I maintain a many projects which are not huge, but some are in the thousands of Github stars and often get an issue or two per day. Across all of my projects I probably see 10-20 new issues per week. My approach is straightforward: help them help themselves. We have some easy things we can do to encourage people to find the information they need to sort out the problem, coaxing out of them debug logs, core dumps, and so on, and sometimes give them our suspicions about the problem. Then we tell them to start digging, and that we're around to answer questions if they need help finding their problem. This process ends with a patch from that user. My projects also often have an IRC channel, where users often help each other with straightforward issues, and we never have to get involved. Sometimes a dev is paying attention and will give them the same rundown. If someone seems enthusiastic about digging and making a fix, they're invited to the dev IRC where they can receive more developer-oriented support in understanding the code and introducing them to the contribution workflow. Sure, it's not the friendliest approach for anyone who isn't willing or able to figure it out themselves. But we're all volunteers and no one is going to volunteer their time to do something they dislike. We volunteered to write code because we like writing code. End-user support is not fun for us. If you like it, volunteering to do it is easy and has basically no onboarding time, you just show up in the support channels and start helping people.
- wink 8y ago
  I think it's a good approach and similarly it works for some projects I help out with. But for some projects it's not working in my experience - especially if you have a lot of non-technical users, for example in a PHP web application. I'm focusing on PHP because you don't just deploy a Python or Ruby web app without at least a bit of developer or *nix experience, whereas shared hosting with "follow these 3 steps and have an ftp client" still works in 2018. In this case the bug reporters are probably not returning, the bug is often fixed in 10mins of developer time and just explaining what all the words mean takes longer than doing it yourself. Sadly these are often also the most ungrateful, so I'd be inclined to just ignore them - but at least we can improve the software after the bug report. Of course not all of them are bad, sometimes you literally have users that wouldn't know how to fix CSS, but they're testing all your new releases and provide feedback - awesome, but not technical.

48 points by ryanar 8y ago

For the "Issue Triage" analysis I would say lines_added,lines_remove,commits,number_issues_involved_in would be interesting to see as well. For example caphrim007 is number 5 in commits over that period but added 5x as many lines of code as next closest committer. However, the code maybe against a new under-used feature so the actual end-user usage could be low. It would also be interesting to juxtapose top committers commit graphs against issue assignment and resolution timeline. When does issue triage by top committers wax and wane? Do big commits (new features) overlap with issue assignment/resolution dates? Does high volume issue assignment/resolution follow big commits?

mlthoughts2018 8y ago

Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. Most of the dysfunction I see in open source projects that take an ambivalent attitude towards the bug fixes and urgent feature needs of long-term users seems based in pure ego. Core devs want to keep being the leading edge designers and implementers of the project and are extremely stingy about letting new or intermediate contributors to the project bring fresh perspective and excitement into big new feature implementation or refactoring. You can make a lot of disingenuous arguments that this is to protect the style and design approach of the original core, but it’s not. It’s just ego. Look, people are obviously free to say if they are dedicating their free time to some open source project, then they only want to work on the aspects of it they like or the aspects that might seem glamorous in a blog post or conference presentation or whatever. Being “allowed” to take that attitude is pretty much inconsequential though. If you do that, your project is entering one of two modes: death mode where new developers realize you will only permit them to work on gruntwork and you lose any capacity to actually fix things because nobody joins your project, or North Korea mode like the linux kernel where some crazed monarch or oligarchs use intimidation and public shaming as primary code review techniques. If you are a really smart core dev of open source, stop working on the big new features. I know it hurts your ego to let your baby into the hands of newbies. Instead, do more code review, tutorials, answers on SO, and go way out of your way to make new contributors feel like you are impressed with their skill, that you want to pair with them through meaningful PRs right away, no “good first task” grunt work ego crap.

thrower123 8y ago
> Core developers that created and grew the project should shift over time to almost exclusively a role of only offering advice on the core implementation and spending their time introducing newbies, patiently answering support questions, and creating tutorials. At this point you need management and support staff. Trying to pound square peg developers into those round holes is rather hopeless, especially when it is free work not paid.
- mlthoughts2018 8y ago
  Sure, I agree it’s still logistically challenging. I’m just claiming the hard part is the ideological hurdle of getting the original core devs of the project to willingly facilitate frequent “changing of the guard” where the burden of critical new features and design is wholeheartedly given to new and intermediate developers of the project, to graciously let other people take the reins and have the core devs with an attitude of service to their community of users, fixing bugs, adding small feature enhancements, and particularly creating excellent documentation and tutorials. That’s the first step. Templates, disqus boards, SO, etc., aren’t going to save you if the core devs view the open source project as a walled garden where they pick and choose what to work on based on a need to “be the one” who is responsible for milestones of implementation.
  - thrower123 8y ago
    What's the incentive to those developers to take on this pain-in-the-ass corporate kind of work, rather than just doing the work that they enjoy that made the project noticeable in the first place? Nothing is owed to anybody, if it's being made into unpleasant management work, you can just pick up your ball and go home and do something else. I'm not really sure I want new developers doing core work on a project, and would be somewhat skeptical of projects that did adopt such practices without heavy oversight.
    - mlthoughts2018 8y ago
      The incentive is just if they want the project to survive and thrive and continue. They may not want this, or may value their pleasure of hacking on it higher than long-term liveness. I’m not making any normative judgments about _whether_ they want one set of preferences or the other, only commenting that it turns out (normatively) badly, from the perspective of the community around the project, if they don’t prioritize the overall liveness of the project (which comes at the cost of “doing as they please”).

Sir_Cmpwn 8y ago

I maintain a many projects which are not huge, but some are in the thousands of Github stars and often get an issue or two per day. Across all of my projects I probably see 10-20 new issues per week. My approach is straightforward: help them help themselves. We have some easy things we can do to encourage people to find the information they need to sort out the problem, coaxing out of them debug logs, core dumps, and so on, and sometimes give them our suspicions about the problem. Then we tell them to start digging, and that we're around to answer questions if they need help finding their problem. This process ends with a patch from that user. My projects also often have an IRC channel, where users often help each other with straightforward issues, and we never have to get involved. Sometimes a dev is paying attention and will give them the same rundown. If someone seems enthusiastic about digging and making a fix, they're invited to the dev IRC where they can receive more developer-oriented support in understanding the code and introducing them to the contribution workflow. Sure, it's not the friendliest approach for anyone who isn't willing or able to figure it out themselves. But we're all volunteers and no one is going to volunteer their time to do something they dislike. We volunteered to write code because we like writing code. End-user support is not fun for us. If you like it, volunteering to do it is easy and has basically no onboarding time, you just show up in the support channels and start helping people.

wink 8y ago
I think it's a good approach and similarly it works for some projects I help out with. But for some projects it's not working in my experience - especially if you have a lot of non-technical users, for example in a PHP web application. I'm focusing on PHP because you don't just deploy a Python or Ruby web app without at least a bit of developer or *nix experience, whereas shared hosting with "follow these 3 steps and have an ftp client" still works in 2018. In this case the bug reporters are probably not returning, the bug is often fixed in 10mins of developer time and just explaining what all the words mean takes longer than doing it yourself. Sadly these are often also the most ungrateful, so I'd be inclined to just ignore them - but at least we can improve the software after the bug report. Of course not all of them are bad, sometimes you literally have users that wouldn't know how to fix CSS, but they're testing all your new releases and provide feedback - awesome, but not technical.