7 ms·

The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything

by kreco 4y ago

The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just a view of what people wants and not how the project should go. Also react-native-fs mentioned in the article only have 4 bugs opened. The rest is just noise and unlabelled issues. Note that there might be a considerable amount of bugs in those unlabelled issues. As a maintainer I should not spend my time to label anything, either you enter it as bug and I'm considering it since bug are supposed to be critical, either it's not and it's going into a sperate queue I can read whenever I have more free time.

Kovah 4y ago
Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEMPLATE https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I really don't want to deal with "XYZ is not working"-types of issues without any context or further information. Feature requests are redirected to the discussion forums first. It works very well for me.
- RobotToaster 4y ago
  >Github isn't really the issue here >requests are redirected to the discussion forums first The fact you're having to hack the forum into a feature request tracker seems like an issue with github?
  - nightpool 4y ago
    The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/codespaces https://github.com/orgs/community/discussions/categories/cod...). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything
    - shkkmo 4y ago
      > The forum was built to be a feature request tracker. It was explicitly built to not be a tracker, but a discussion platform. The documentation describes them thus: "Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues." Thus, once a discussion needs to be tracked or linked to code changes, an issue is required. I'm in favor of providing more tools to orgnizations, but in practice I see very few to none of the projects that I depend on or interface with that actually use github discussions (I presume that is because so many discussions eventually need to be tracked or linked to code changes.) > It's used extensively for that purpose at Github Yet, when I look at the Discussions discussion, it's full of random junk, much of which looks like poorly written bug reports.
- sodality2 4y ago
  It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"
  - zozbot234 4y ago
    GitHub's issue tracking has tags, which can be used for this.
    - mort96 4y ago
      When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out. GitHub doesn't offer great tools to clearly separate bug reports, improvement suggestions and feature requests.
      - zozbot234 4y ago
        > until you manually go and filter them out. Filtering by tag only takes a single click. It's not hard.
        mort96 4y ago
        Filtering takes two clicks with potential scrolling in between actually, not that it makes a big difference. You probably have multiple kinds of issues you care about, and multiple kinds you don't care about, which takes significantly more work. But this whole discussion about how many clicks it takes to do what is really off topic, the issue is with the lack of a clear separation, and the fact that all the issues are bunched together by default -- that filtering out the issues you don't care about takes any clicks at all -- contributes to that.
        4y ago
- ilyt 4y ago
  It is an issue here. Passerby looking at main page will see "300 issues open", not "5 bugs and 295 feature requests open"
  - remram 4y ago
    Do you have any evidence that passerbys think this way? Scikit-learn has 1.5k issues, react has 900, I don't think it is driving them away?
    - iudqnolq 4y ago
      Personally I skim a sample of issues before adding a dependency. The main thing I look at is what happens after high quality bug reports are filed. The top line number doesn't bother me much.
  - madeofpalk 4y ago
    I have seen projects use Discussions instead for feature requests, and (open) issues for things the maintainers have a pretty solid understanding of things that should be worked on and closed.
    - xur17 4y ago
      This seems like a great way to handle it.
  - lcnPylGDnU4H9OF 4y ago
    It could still be worth saying "no", per the article, to the 295 open feature requests. The fact that the maintainers have not (yet) declined these requests, resulting in this seemingly inflated total of 300 "Issues", is not necessarily a problem with github.
- qikInNdOutReply 4y ago
  There is a issue with issues there though. They do not automatically parse for similar issues and suggest adding your case to them.
  - eropple 4y ago
    That would be a nice add-on, but IME, most people just click straight through it.
    - qikInNdOutReply 4y ago
      Then allow them to auto-cluster by similarity for those who have to read the mess, also sort by quality.
      - eropple 4y ago
        Now that's an idea. I like that.
- croes 4y ago
  Your project has 65 issues. Without looking into the details I could assume these are 65 bugs.
  - shkkmo 4y ago
    That seems like a bad assumption. Even if there are 65 bugs, without taking a look at a sample of them you have no idea of the severity or relevance of those bugs. Looks at a simplistic number without digging into the details will always be a poor way to evaluate the health of a project.
- xphos 4y ago
  I think this is also an example of bad default options. You should not have to setup a bug report form to get correct tagging. No one writes bugless code it should be a default option to have a bug report or a feature request. I understand the other fluff around separate queues but for something a large as GitHub good default options are really important.
  - Kovah 4y ago
    That's absolutely a valid point. However, if Github would have set something like this as a default, there would be a lot of people who would complain about it being too opinionated. Being open first with many options to customize and "lock down" is probably a good compromise.
- lifeisstillgood 4y ago
  That's a fantastic way to setup your github - I shall steal it asap :-)
heikkilevanto 4y ago
A simple solution is to close all feature requests with a tag that lists is as a request, and a comment that explains that you may go through the requests some day when you don't have many bugs to fix. Or if a customer is willing to pay for an extra feature. Maybe even add a tag to indicate that this feature would be a good place for new contributors to start. Of course, you then get the same feature requests multiple times.
- jrochkind1 4y ago
  Note however that the scenario in the OP that leads to ruin starts with an external contributor contributing a feature. Someone other than the maintainer contributing the PR doesn't really solve the problem; the features still leads to complexity and maintanance burden that inevitably falls on the maintainers.
- kreco 4y ago
  While I understand and agree to the solution you provide, I would dare to call it a workaround. Since Github default culture is to use issues in a certain way, in which the maintainers are actually the bottleneck, most people will keep using it thinking it's the standard and correct way to do it. Unrelated to the above, you mentioned the paid extra feature, I really wish to see this implemented in a source forge to see how it goes.
- SoftTalker 4y ago
  I've seen some projects that say almost exactly this: Feature requests will be closed. If you have a contribution or patch, I'll look at it. If you want to pay for something, contact me.
otikik 4y ago
You can use GitHub discussions for exactly that.
greggman3 4y ago
this sounds like an engineer fighting against reality. If there is a way to file bugs people will use it to file feature requests. It will be up to you to filter them. It doesn't matter what system you use
alixanderwang 4y ago
Since it's not mentioned, we also use as TODOs/issue-tracker. https://github.com/terrastruct/d2/issues https://github.com/terrastruct/d2/issues We actually switched from Linear to Github Issues because of how nice it is to have the TODOs colocated with PRs and code. I suspect some users may drive by and be turned away from the sheer number of open Issues, and that's okay to me. I hate projects that try to keep Issues to 0 -- especially the ones that auto-stale. It just makes it harder for me to see if the Issue was actually resolved or not.

by kreco 4y ago

Kovah 4y ago

Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEMPLATE https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I really don't want to deal with "XYZ is not working"-types of issues without any context or further information. Feature requests are redirected to the discussion forums first. It works very well for me.

RobotToaster 4y ago
>Github isn't really the issue here >requests are redirected to the discussion forums first The fact you're having to hack the forum into a feature request tracker seems like an issue with github?
- nightpool 4y ago
  The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/codespaces https://github.com/orgs/community/discussions/categories/cod...). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything
  - shkkmo 4y ago
    > The forum was built to be a feature request tracker. It was explicitly built to not be a tracker, but a discussion platform. The documentation describes them thus: "Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues." Thus, once a discussion needs to be tracked or linked to code changes, an issue is required. I'm in favor of providing more tools to orgnizations, but in practice I see very few to none of the projects that I depend on or interface with that actually use github discussions (I presume that is because so many discussions eventually need to be tracked or linked to code changes.) > It's used extensively for that purpose at Github Yet, when I look at the Discussions discussion, it's full of random junk, much of which looks like poorly written bug reports.
sodality2 4y ago
It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"
- zozbot234 4y ago
  GitHub's issue tracking has tags, which can be used for this.
  - mort96 4y ago
    When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out. GitHub doesn't offer great tools to clearly separate bug reports, improvement suggestions and feature requests.
    - zozbot234 4y ago
      > until you manually go and filter them out. Filtering by tag only takes a single click. It's not hard.
      - mort96 4y ago
        Filtering takes two clicks with potential scrolling in between actually, not that it makes a big difference. You probably have multiple kinds of issues you care about, and multiple kinds you don't care about, which takes significantly more work. But this whole discussion about how many clicks it takes to do what is really off topic, the issue is with the lack of a clear separation, and the fact that all the issues are bunched together by default -- that filtering out the issues you don't care about takes any clicks at all -- contributes to that.
        4y ago
ilyt 4y ago
It is an issue here. Passerby looking at main page will see "300 issues open", not "5 bugs and 295 feature requests open"
- remram 4y ago
  Do you have any evidence that passerbys think this way? Scikit-learn has 1.5k issues, react has 900, I don't think it is driving them away?
  - iudqnolq 4y ago
    Personally I skim a sample of issues before adding a dependency. The main thing I look at is what happens after high quality bug reports are filed. The top line number doesn't bother me much.
- madeofpalk 4y ago
  I have seen projects use Discussions instead for feature requests, and (open) issues for things the maintainers have a pretty solid understanding of things that should be worked on and closed.
  - xur17 4y ago
    This seems like a great way to handle it.
- lcnPylGDnU4H9OF 4y ago
  It could still be worth saying "no", per the article, to the 295 open feature requests. The fact that the maintainers have not (yet) declined these requests, resulting in this seemingly inflated total of 300 "Issues", is not necessarily a problem with github.
qikInNdOutReply 4y ago
There is a issue with issues there though. They do not automatically parse for similar issues and suggest adding your case to them.
- eropple 4y ago
  That would be a nice add-on, but IME, most people just click straight through it.
  - qikInNdOutReply 4y ago
    Then allow them to auto-cluster by similarity for those who have to read the mess, also sort by quality.
    - eropple 4y ago
      Now that's an idea. I like that.
croes 4y ago
Your project has 65 issues. Without looking into the details I could assume these are 65 bugs.
- shkkmo 4y ago
  That seems like a bad assumption. Even if there are 65 bugs, without taking a look at a sample of them you have no idea of the severity or relevance of those bugs. Looks at a simplistic number without digging into the details will always be a poor way to evaluate the health of a project.
xphos 4y ago
I think this is also an example of bad default options. You should not have to setup a bug report form to get correct tagging. No one writes bugless code it should be a default option to have a bug report or a feature request. I understand the other fluff around separate queues but for something a large as GitHub good default options are really important.
- Kovah 4y ago
  That's absolutely a valid point. However, if Github would have set something like this as a default, there would be a lot of people who would complain about it being too opinionated. Being open first with many options to customize and "lock down" is probably a good compromise.
lifeisstillgood 4y ago
That's a fantastic way to setup your github - I shall steal it asap :-)

heikkilevanto 4y ago

A simple solution is to close all feature requests with a tag that lists is as a request, and a comment that explains that you may go through the requests some day when you don't have many bugs to fix. Or if a customer is willing to pay for an extra feature. Maybe even add a tag to indicate that this feature would be a good place for new contributors to start. Of course, you then get the same feature requests multiple times.

jrochkind1 4y ago
Note however that the scenario in the OP that leads to ruin starts with an external contributor contributing a feature. Someone other than the maintainer contributing the PR doesn't really solve the problem; the features still leads to complexity and maintanance burden that inevitably falls on the maintainers.
kreco 4y ago
While I understand and agree to the solution you provide, I would dare to call it a workaround. Since Github default culture is to use issues in a certain way, in which the maintainers are actually the bottleneck, most people will keep using it thinking it's the standard and correct way to do it. Unrelated to the above, you mentioned the paid extra feature, I really wish to see this implemented in a source forge to see how it goes.
SoftTalker 4y ago
I've seen some projects that say almost exactly this: Feature requests will be closed. If you have a contribution or patch, I'll look at it. If you want to pay for something, contact me.

otikik 4y ago

You can use GitHub discussions for exactly that.

greggman3 4y ago

this sounds like an engineer fighting against reality. If there is a way to file bugs people will use it to file feature requests. It will be up to you to filter them. It doesn't matter what system you use

alixanderwang 4y ago

Since it's not mentioned, we also use as TODOs/issue-tracker. https://github.com/terrastruct/d2/issues https://github.com/terrastruct/d2/issues We actually switched from Linear to Github Issues because of how nice it is to have the TODOs colocated with PRs and code. I suspect some users may drive by and be turned away from the sheer number of open Issues, and that's okay to me. I hate projects that try to keep Issues to 0 -- especially the ones that auto-stale. It just makes it harder for me to see if the Issue was actually resolved or not.