10 ms·

Seems like the issue is... issues. Some projects get so popular that it's a full time job just to respond to issues that lack information. I've been in softwar

by bphogan 11y ago

Seems like the issue is... issues. Some projects get so popular that it's a full time job just to respond to issues that lack information. I've been in software for a long time. There's no tool that solves this problem. People who don't know your software don't know how to report issues. They don't know the keywords or nomenclature to search for pre-existing error messages either. Switching to another tool won't solve this problem they're having. Typical engineers - they think issue templates will help. No. I'll just fill in whatever gets me past the validation cos I'm frustrated. This might be unpopular, but you're under no obligation to answer those issues or even have a public issue tracker at all. Turn the issue tracker off if it's frustrating, and use a private issue tracker for the core team. Or find some students that want to break into open source and have them be 1st level triage for your issues. It's a people problem, not a technology problem. Too many developers forget that software development, even open-source, is 20% code and 80% people. Documentation and support are a huge part of software. And software only goes so far to solving that in my experience.

joshmanders 11y ago
> Or find some students that want to break into open source and have them be 1st level triage for your issues. Which I had offered as a solution in the thread, but was ultimately shot down with "It's 2016, we have bots that can do that." Clearly the bots don't work if it's still a problem.
- bphogan 11y ago
  Yup. My students are always asking how they can get involved in open source....
  - joshmanders 11y ago
    Lots of talk around the OSS world on how to "get involved with open source" and this is a great solution to both problems. Newbies can start getting involved by triaging issues, and projects can alleviate some of the pains by letting them do it. It's a win win.
    - maaku 11y ago
      As long as the newbie doesn't walk away feeling like they've been shunted into the kindergarten playpen. But so long as you get ahead of that expectation mis-match, it actually is a really good way to get to know both a project and its surrounding development culture.
      - OJFord 11y ago
        I'm a student, I don't think it would feel like that at all (as long as the attitude of other team members didn't make it so). There have been days where I've actively searched for some OSS project that is accessible enough for me to work on - because usually the ideas I have myself are things I'm not capable of! Or I just need to think more about how to get started, and when in this mood I'd rather just get hacking on someone else's project's issue. My point is, issue triaging could be a great way to learn the ropes of a project (and get to know the team a bit), and you'd probably find yourself occasionally (then gradually more often) thinking "hey, actually I reckon I can have a crack at this myself". That'd be really satisfying for a never-contributed-before fresher.
- fweespeech 11y ago
  To be honest, this is a problem that has to be solved by cash/donations. 1st level triage for issues could be done by developer in the Phillipines on Upwork for like $5-10/hr. The problem really is they've hit a scale where they need a human CSR to handle their 1st level triage but they don't have the cash to pay one. Volunteers find the work mind numbing enough they refuse to do it for long generally.
  - bphogan 11y ago
    Yes. I agree. Cash would solve this. All the people making money on books about ES6 could kick in. All the folks making screencasts could kick in. All the companies making money on open-source could kick in. And volunteers? They should cycle out and move up into more interesting work, making room for new people to do that. That's what I was thinking.
    - syntheticnature 11y ago
      All these folks could kick in, but will they? Not that I'm saying that volunteers are better -- they asked, no one stepped up, which means to me that volunteers are a non-starter.
      - fweespeech 11y ago
        It's in their best interest to. If the cow you milk dies through neglect, you have to find another.
  - dec0dedab0de 11y ago
    That might encourage false reports to keep the work available. It is a good idea though.
- jarek 11y ago
  Do any students/newbies actually want to triage issues, or is it just something the old hands thought up and think might work nicely?
  - op00to 11y ago
    I triage where possible in projects that are important to me, because when I have a problem, I expect my issue to be triaged in return. I'm not a student/newbie, but I'm not a coder and still desire to contribute where I can.
  - bphogan 11y ago
    Many 1st semester students want to get involved and can't code yet. And I know they'd jump at this.
    - deleted 11y ago
      [deleted]
    - jarek 11y ago
      How many have you suggested volunteer, and what were their thoughts after a semester?
      - bphogan 11y ago
        About 60 a semester. Number that attempt to get involved is unknown. I require 1st semester students to push final projects to Github public repositories so they learn Git. Biggest problem is that they can't program very well yet but want to contribute. So any low-hanging fruit is welcome, really.
        newjersey 11y ago
        I've been working as a programmer for a few years and I can't program very well. I can get things done but it takes longer as I'm constantly distracting myself. I want to contribute as well, particularly with compiling binaries and easier stuff but I don't know where to start.
hoodoof 11y ago
Damn users!
diakritikal 11y ago
Should issue management be complicated for most projects? I suppose the polar opposite of guthub issues is something like bugzilla or jira. Both of which I've seen cause enough friction that to stymie projects.
cwyers 11y ago
> Switching to another tool won't solve this problem they're having. Typical engineers - they think issue templates will help. No. I'll just fill in whatever gets me past the validation cos I'm frustrated. Users won't read: http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html http://www.joelonsoftware.com/uibook/chapters/fog0000000062....
- hk__2 11y ago
  Users don’t even read the error messages, let alone the documentation.
- mixedCase 11y ago
  ~closed as Incomplete. Please complete the form properly :^)
onlyrealcuzzo 11y ago
In fairness, he makes a lot of points that GitHub is particularly awful at, specifically things that aren't very relevant to enterprises (who pay their bills) and therefore aren't priorities for GitHub. You're totally right about software being more about people than about code. That being said, I think maybe you're underestimating just how many issues ESLint receives and how willing people are to volunteer time to the project. They've received almost 2500 issues and have essentially 5 active developers. Yes, you're one hundred percent correct that issues are the problem here. That's a lot of issues for five people. Period. You're being a little lenient on GitHub's behalf by not weighting how poorly it does issue tracking which expounds their problem a great deal. They're not "typical dumb engineers". They mention nowhere that they'll somehow end up with less bugs if they leave GitHub. But they believe they'll be able to more accurately assess issues and turn them around faster by using a different platform--which if you're familiar with the alternatives, it isn't the completely facetious assumption you cut it out to be. Sorry if that comes off aggressive. Not intended. You make great points. Just wanted to reiterate that GitHub has some blame here...
- bphogan 11y ago
  I didn't say typical dumb engineers. I said typical engineers. Looking for technical solutions when the problems are not technical. That's pretty typical in my experience. I'm not underestimating the issues they get. I looked at it before I wrote what I wrote. It's a lot. But I'm not going to feel bad for them. They have a massively successful open source project. And only 5 people. Despite lots of use. I wonder why more people aren't getting involved to triage the issues instead of looking for a technical solution? I'm not being lenient on Github either. Their issue tracker is incredibly limited. It always was. I remember when they launched it and they were very clear about its simple limitations. Simple is good. Until you're a massive opensource project using it as a catch-all bin for troubleshooting issues.
  - rms_returns 11y ago
    > I wonder why more people aren't getting involved to triage the issues instead of looking for a technical solution? Its the same old Cathedral vs Bazaar argument. These issues existed even in the time of Richard Stallman and Linus Torvalds. Linus liked the bazaar style of development accepting patches and fixes from just about anyone, while RMS liked the cathedral style of sticking to a small group of chosen devs. But issues used to get solved despite the lack of github and a lack of a decent bug-tracker in those times! They used to get solved by using a simple mailing list, I think your earlier conclusion is right: its a people problem, not technical that is happening now.
derefr 11y ago
Issue templates, no. An issue spam filter, on the other hand—especially one the submitting user knows exists...
sytse 11y ago
No tool will completely solve it, but there are a lot of changes you can make to an issue tracker to deal with increasing popularity. For example allowing people to add emoji's so that you don't get an email with a +1 comment helps a lot. For the rest of the things we did at GitLab please see our 'Dear open source maintainers' letter https://about.gitlab.com/2016/01/15/making-gitlab-better-for-large-open-source-projects/ https://about.gitlab.com/2016/01/15/making-gitlab-better-for... BTW I also commented in the issue https://github.com/eslint/eslint/issues/5205#issuecomment-183062268 https://github.com/eslint/eslint/issues/5205#issuecomment-18...
Fomite 11y ago
"Switching to another tool won't solve this problem they're having." It will if those users don't follow them from GitHub. Whether this is a bug or a feature is left as an exercise to the reader.
- bsder 11y ago
  I would say feature. If you have to sign up to file a bug, the bug is going to be important to you. You're likely to put a bit more effort into making sure the report is well-written. If you already have a github account, you will probably simply do a drive-by bug report on anything that looks like a bug. Bug reports are the lowest level of "contributions", and losing some people filing them isn't a big loss.
  - rms_returns 11y ago
    > If you have to sign up to file a bug, the bug is going to be important to you. This. That's the reason why bugzillas rock! Visit the GNOME bugzilla, Red Hat bugzilla and even Mozilla bugzilla for instance and have a look. Its always organized, focused and in problem-solving mode. Unlike Github issues, people don't stampede there to just say "Hi" or "How may I use this thingy?", they bring their actual problems in all seriousness (because they have to register, verify their emails and then login just for the sake of posting an issue)
    - eterm 11y ago
      Bugzilla is a little too unfriendly, the search can be a pain so its hard to know sometimes whether you're submtting a dupe. And of course even with the best of intentions, most issues raised will still be NotBugs or other time wasters. (I'm guilty of that myself, just yesterday I reported what I thought was a bug in Firefox but turned out to be chrome and IE not implementing the spec and us using their incorrrect behaviour).
      - rms_returns 11y ago
        > just yesterday I reported what I thought was a bug in Firefox but turned out to be chrome and IE not implementing the spec and us using their incorrrect behaviour That's still loads better than the average issue reporter on Github issues. Though it was not a bug in your case, your effort was genuine and deserved some real attention. If this were the github tracker, your genunie question would have been piled and lost under tons of useless ones.
maaku 11y ago
> I've been in software for a long time. There's no tool that solves this problem. There's not a generic tool, but there's often a lot that can be done one the client side to gather relevant information for a bug report. This is why, e.g., many linux distributions have a built-in bug reporting tool -- it will also hoover up non-personal information that might be relevant to the bug you are filing -- packages installed, error stats, etc.
- bphogan 11y ago
  Imagine running eslint --itbroke and a log was copied to your clipboard so you could paste it in...
  - jdbernard 11y ago
    Imagine that command making an API call to an improved GitHub issue system with facilities to organize and accommodate more structured submissions.
pbreit 11y ago
143 issues over 2 years is an "onslaught"? Edit: my bad, 143 is only "open" issues. Nearly 3,000 total.
- joshmanders 11y ago
  2,915 have already been closed. Averages out to 4 new issues a day.
- thebouv 11y ago
  147 open, 2915 closed. First page of issues is 25 in past 8 days. Not sure what determines an onslaught, but just so the numbers are clear.
  - majewsky 11y ago
    The "onslaught" is very relative to how many time you can afford to spend on the project at all. If you can afford to spend one hour per week, then triaging 25 issues per week might eat all of that. If you can afford to spend one hour per day, then issue triaging will only be a small part of your daily routine.
jowiar 11y ago
The crazy part is that this is absolutely a solved problem. I'm not sure if everyone misses this due to Linus-worship, holding him up as an example of how to run an OSS project (which... he isn't a good one), but most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here. I'd love to see everyone: (1) Buy their nearest PM an appreciative beer, thanking them for keeping this off you at your day job. (2) Recruit somebody with this experience to your project. It's unreasonable to expect that OSS is a developer-only world, when closed-source software doesn't function that way. Changing the culture of OSS to involve PMs when projects hit a significant size and respect their contributions would be excellent.
- cpeterso 11y ago
  What is "Pls"? Linus also delegates to his kernel "lieutenants" to scale Linux development.
  - jowiar 11y ago
    A typo (now fixed).
- sangnoir 11y ago
  > most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here Good PMs are hard to find, and the problem is far from solved. Some PMs add to the problem by adding more forms with even more mandatory fields that have very little to do with actual development and a lot to do with feeding into their "Project Reports". So, don't buy that beer too hastily.
  - cloverich 11y ago
    > Good PMs are hard to find I'd take this further -- I think finding good PM's is harder than finding good dev's. I'm not sure why exactly. I bet you'd find a lot of dev's who think their PM does the opposite of their job (that is, creates more work for them).
alkonaut 11y ago
You make a few fair points, but at least having a mandatory "version" field for a bug report feels like a sensible requirement for any issue tracker with a large backlog covering many versions. Solving what can be done by a form validator with paid staff just doesn't sound right. GitHub doesn't need to become jira, but just promoting the tag system to a custom field system would help.
misiti3780 11y ago
Disagree - GitHub is the Facebook of open source which is good - but its popularity sets the bar low for adding an issue (especially a dupe or something that isn't even a bug) - go try to create a issue for Linux one of the Apache projects not hosted on GitHub (not taking about mirrors) and you will see it is considerably harder - that leads to attrition which leads to less "fake" issues
EugeneOZ 11y ago
"Turn off public issues tracker" it's the most effective way to kill your product. See Opera as example.
dragonsh 11y ago
There are two solutions to this I think they can use a really distributed version control including tickets and wiki as part of the repository as it is done in fossil scm (http://www.fossil-scm.org/ http://www.fossil-scm.org/) or just use trac with ticket triage like its being done with http://code.djangoproject.com/ http://code.djangoproject.com/ My personal suggestion is to get out of github as the platform is not open source and there are no community process to enhance or change it. Its just another sourceforge with flashy interface.
egeozcan 11y ago
The issue is very simple IMHO: The low number of maintainers per user. To solve this, you can start ignoring issues, recruit more maintainers or make maintainers more effective. They are trying the latter, which seems like a good compromise.

by bphogan 11y ago

joshmanders 11y ago

> Or find some students that want to break into open source and have them be 1st level triage for your issues. Which I had offered as a solution in the thread, but was ultimately shot down with "It's 2016, we have bots that can do that." Clearly the bots don't work if it's still a problem.

bphogan 11y ago
Yup. My students are always asking how they can get involved in open source....
- joshmanders 11y ago
  Lots of talk around the OSS world on how to "get involved with open source" and this is a great solution to both problems. Newbies can start getting involved by triaging issues, and projects can alleviate some of the pains by letting them do it. It's a win win.
  - maaku 11y ago
    As long as the newbie doesn't walk away feeling like they've been shunted into the kindergarten playpen. But so long as you get ahead of that expectation mis-match, it actually is a really good way to get to know both a project and its surrounding development culture.
    - OJFord 11y ago
      I'm a student, I don't think it would feel like that at all (as long as the attitude of other team members didn't make it so). There have been days where I've actively searched for some OSS project that is accessible enough for me to work on - because usually the ideas I have myself are things I'm not capable of! Or I just need to think more about how to get started, and when in this mood I'd rather just get hacking on someone else's project's issue. My point is, issue triaging could be a great way to learn the ropes of a project (and get to know the team a bit), and you'd probably find yourself occasionally (then gradually more often) thinking "hey, actually I reckon I can have a crack at this myself". That'd be really satisfying for a never-contributed-before fresher.
fweespeech 11y ago
To be honest, this is a problem that has to be solved by cash/donations. 1st level triage for issues could be done by developer in the Phillipines on Upwork for like $5-10/hr. The problem really is they've hit a scale where they need a human CSR to handle their 1st level triage but they don't have the cash to pay one. Volunteers find the work mind numbing enough they refuse to do it for long generally.
- bphogan 11y ago
  Yes. I agree. Cash would solve this. All the people making money on books about ES6 could kick in. All the folks making screencasts could kick in. All the companies making money on open-source could kick in. And volunteers? They should cycle out and move up into more interesting work, making room for new people to do that. That's what I was thinking.
  - syntheticnature 11y ago
    All these folks could kick in, but will they? Not that I'm saying that volunteers are better -- they asked, no one stepped up, which means to me that volunteers are a non-starter.
    - fweespeech 11y ago
      It's in their best interest to. If the cow you milk dies through neglect, you have to find another.
- dec0dedab0de 11y ago
  That might encourage false reports to keep the work available. It is a good idea though.
jarek 11y ago
Do any students/newbies actually want to triage issues, or is it just something the old hands thought up and think might work nicely?
- op00to 11y ago
  I triage where possible in projects that are important to me, because when I have a problem, I expect my issue to be triaged in return. I'm not a student/newbie, but I'm not a coder and still desire to contribute where I can.
- bphogan 11y ago
  Many 1st semester students want to get involved and can't code yet. And I know they'd jump at this.
  - deleted 11y ago
    [deleted]
  - jarek 11y ago
    How many have you suggested volunteer, and what were their thoughts after a semester?
    - bphogan 11y ago
      About 60 a semester. Number that attempt to get involved is unknown. I require 1st semester students to push final projects to Github public repositories so they learn Git. Biggest problem is that they can't program very well yet but want to contribute. So any low-hanging fruit is welcome, really.
      - newjersey 11y ago
        I've been working as a programmer for a few years and I can't program very well. I can get things done but it takes longer as I'm constantly distracting myself. I want to contribute as well, particularly with compiling binaries and easier stuff but I don't know where to start.

hoodoof 11y ago

Damn users!

diakritikal 11y ago

Should issue management be complicated for most projects? I suppose the polar opposite of guthub issues is something like bugzilla or jira. Both of which I've seen cause enough friction that to stymie projects.

cwyers 11y ago

> Switching to another tool won't solve this problem they're having. Typical engineers - they think issue templates will help. No. I'll just fill in whatever gets me past the validation cos I'm frustrated. Users won't read: http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

hk__2 11y ago
Users don’t even read the error messages, let alone the documentation.
mixedCase 11y ago
~closed as Incomplete. Please complete the form properly :^)

onlyrealcuzzo 11y ago

In fairness, he makes a lot of points that GitHub is particularly awful at, specifically things that aren't very relevant to enterprises (who pay their bills) and therefore aren't priorities for GitHub. You're totally right about software being more about people than about code. That being said, I think maybe you're underestimating just how many issues ESLint receives and how willing people are to volunteer time to the project. They've received almost 2500 issues and have essentially 5 active developers. Yes, you're one hundred percent correct that issues are the problem here. That's a lot of issues for five people. Period. You're being a little lenient on GitHub's behalf by not weighting how poorly it does issue tracking which expounds their problem a great deal. They're not "typical dumb engineers". They mention nowhere that they'll somehow end up with less bugs if they leave GitHub. But they believe they'll be able to more accurately assess issues and turn them around faster by using a different platform--which if you're familiar with the alternatives, it isn't the completely facetious assumption you cut it out to be. Sorry if that comes off aggressive. Not intended. You make great points. Just wanted to reiterate that GitHub has some blame here...

bphogan 11y ago
I didn't say typical dumb engineers. I said typical engineers. Looking for technical solutions when the problems are not technical. That's pretty typical in my experience. I'm not underestimating the issues they get. I looked at it before I wrote what I wrote. It's a lot. But I'm not going to feel bad for them. They have a massively successful open source project. And only 5 people. Despite lots of use. I wonder why more people aren't getting involved to triage the issues instead of looking for a technical solution? I'm not being lenient on Github either. Their issue tracker is incredibly limited. It always was. I remember when they launched it and they were very clear about its simple limitations. Simple is good. Until you're a massive opensource project using it as a catch-all bin for troubleshooting issues.
- rms_returns 11y ago
  > I wonder why more people aren't getting involved to triage the issues instead of looking for a technical solution? Its the same old Cathedral vs Bazaar argument. These issues existed even in the time of Richard Stallman and Linus Torvalds. Linus liked the bazaar style of development accepting patches and fixes from just about anyone, while RMS liked the cathedral style of sticking to a small group of chosen devs. But issues used to get solved despite the lack of github and a lack of a decent bug-tracker in those times! They used to get solved by using a simple mailing list, I think your earlier conclusion is right: its a people problem, not technical that is happening now.

derefr 11y ago

Issue templates, no. An issue spam filter, on the other hand—especially one the submitting user knows exists...

sytse 11y ago

No tool will completely solve it, but there are a lot of changes you can make to an issue tracker to deal with increasing popularity. For example allowing people to add emoji's so that you don't get an email with a +1 comment helps a lot. For the rest of the things we did at GitLab please see our 'Dear open source maintainers' letter https://about.gitlab.com/2016/01/15/making-gitlab-better-for-large-open-source-projects/ https://about.gitlab.com/2016/01/15/making-gitlab-better-for... BTW I also commented in the issue https://github.com/eslint/eslint/issues/5205#issuecomment-183062268 https://github.com/eslint/eslint/issues/5205#issuecomment-18...

Fomite 11y ago

"Switching to another tool won't solve this problem they're having." It will if those users don't follow them from GitHub. Whether this is a bug or a feature is left as an exercise to the reader.

bsder 11y ago
I would say feature. If you have to sign up to file a bug, the bug is going to be important to you. You're likely to put a bit more effort into making sure the report is well-written. If you already have a github account, you will probably simply do a drive-by bug report on anything that looks like a bug. Bug reports are the lowest level of "contributions", and losing some people filing them isn't a big loss.
- rms_returns 11y ago
  > If you have to sign up to file a bug, the bug is going to be important to you. This. That's the reason why bugzillas rock! Visit the GNOME bugzilla, Red Hat bugzilla and even Mozilla bugzilla for instance and have a look. Its always organized, focused and in problem-solving mode. Unlike Github issues, people don't stampede there to just say "Hi" or "How may I use this thingy?", they bring their actual problems in all seriousness (because they have to register, verify their emails and then login just for the sake of posting an issue)
  - eterm 11y ago
    Bugzilla is a little too unfriendly, the search can be a pain so its hard to know sometimes whether you're submtting a dupe. And of course even with the best of intentions, most issues raised will still be NotBugs or other time wasters. (I'm guilty of that myself, just yesterday I reported what I thought was a bug in Firefox but turned out to be chrome and IE not implementing the spec and us using their incorrrect behaviour).
    - rms_returns 11y ago
      > just yesterday I reported what I thought was a bug in Firefox but turned out to be chrome and IE not implementing the spec and us using their incorrrect behaviour That's still loads better than the average issue reporter on Github issues. Though it was not a bug in your case, your effort was genuine and deserved some real attention. If this were the github tracker, your genunie question would have been piled and lost under tons of useless ones.

maaku 11y ago

> I've been in software for a long time. There's no tool that solves this problem. There's not a generic tool, but there's often a lot that can be done one the client side to gather relevant information for a bug report. This is why, e.g., many linux distributions have a built-in bug reporting tool -- it will also hoover up non-personal information that might be relevant to the bug you are filing -- packages installed, error stats, etc.

bphogan 11y ago
Imagine running eslint --itbroke and a log was copied to your clipboard so you could paste it in...
- jdbernard 11y ago
  Imagine that command making an API call to an improved GitHub issue system with facilities to organize and accommodate more structured submissions.

pbreit 11y ago

143 issues over 2 years is an "onslaught"? Edit: my bad, 143 is only "open" issues. Nearly 3,000 total.

joshmanders 11y ago
2,915 have already been closed. Averages out to 4 new issues a day.
thebouv 11y ago
147 open, 2915 closed. First page of issues is 25 in past 8 days. Not sure what determines an onslaught, but just so the numbers are clear.
- majewsky 11y ago
  The "onslaught" is very relative to how many time you can afford to spend on the project at all. If you can afford to spend one hour per week, then triaging 25 issues per week might eat all of that. If you can afford to spend one hour per day, then issue triaging will only be a small part of your daily routine.

jowiar 11y ago

The crazy part is that this is absolutely a solved problem. I'm not sure if everyone misses this due to Linus-worship, holding him up as an example of how to run an OSS project (which... he isn't a good one), but most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here. I'd love to see everyone: (1) Buy their nearest PM an appreciative beer, thanking them for keeping this off you at your day job. (2) Recruit somebody with this experience to your project. It's unreasonable to expect that OSS is a developer-only world, when closed-source software doesn't function that way. Changing the culture of OSS to involve PMs when projects hit a significant size and respect their contributions would be excellent.

cpeterso 11y ago
What is "Pls"? Linus also delegates to his kernel "lieutenants" to scale Linux development.
- jowiar 11y ago
  A typo (now fixed).
sangnoir 11y ago
> most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here Good PMs are hard to find, and the problem is far from solved. Some PMs add to the problem by adding more forms with even more mandatory fields that have very little to do with actual development and a lot to do with feeding into their "Project Reports". So, don't buy that beer too hastily.
- cloverich 11y ago
  > Good PMs are hard to find I'd take this further -- I think finding good PM's is harder than finding good dev's. I'm not sure why exactly. I bet you'd find a lot of dev's who think their PM does the opposite of their job (that is, creates more work for them).

alkonaut 11y ago

You make a few fair points, but at least having a mandatory "version" field for a bug report feels like a sensible requirement for any issue tracker with a large backlog covering many versions. Solving what can be done by a form validator with paid staff just doesn't sound right. GitHub doesn't need to become jira, but just promoting the tag system to a custom field system would help.

misiti3780 11y ago

Disagree - GitHub is the Facebook of open source which is good - but its popularity sets the bar low for adding an issue (especially a dupe or something that isn't even a bug) - go try to create a issue for Linux one of the Apache projects not hosted on GitHub (not taking about mirrors) and you will see it is considerably harder - that leads to attrition which leads to less "fake" issues

EugeneOZ 11y ago

"Turn off public issues tracker" it's the most effective way to kill your product. See Opera as example.

dragonsh 11y ago

There are two solutions to this I think they can use a really distributed version control including tickets and wiki as part of the repository as it is done in fossil scm (http://www.fossil-scm.org/ http://www.fossil-scm.org/) or just use trac with ticket triage like its being done with http://code.djangoproject.com/ http://code.djangoproject.com/ My personal suggestion is to get out of github as the platform is not open source and there are no community process to enhance or change it. Its just another sourceforge with flashy interface.

egeozcan 11y ago

The issue is very simple IMHO: The low number of maintainers per user. To solve this, you can start ignoring issues, recruit more maintainers or make maintainers more effective. They are trying the latter, which seems like a good compromise.