6 ms·

Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Before Github, it wouldn't have come acros

by wott 6y ago

Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Before Github, it wouldn't have come across any sane mind to file a feature request or other discussion/information under the name 'issue', for... they are not issues. It would have gone on a mailing-list (occasionally a web-forum). Issues (identified bugs) on the bug tracker, and the rest in a place of discussion.

nickjj 6y ago
> Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Agreed. But GitHub is also slowly fixing this. For example the "Discussions" beta feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions https://github.com/ImageMagick/ImageMagick/discussions. It's only available on a small subset of repos tho and it's something you can turn on and off at the repo level. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions https://github.com/nickjj/flask-db/discussions. I hope the Discussions feature becomes generally available soon.
- wott 6y ago
  Yes. On the other hand, the goal is also to increase the vendor lock-in, by providing everything inside their garden walls, so that people keep going further into giving up any side channel and into putting all their eggs into the same Github basket.
  - nickjj 6y ago
    > On the other hand, the goal is also to increase the vendor lock-in, by providing everything inside their garden walls, so that people keep going further into giving up any side channel and into putting all their eggs into the same Github basket. That's also true but where do you draw the line with vendor lock-in and convenience? If you use Google's mailing list service then you're locked into Google. What if they decide to drop that like many other services in the past? If you use a self hosted forum / mailing list instead, the repo owner is on the hook for setting up and configuring a server along with potentially registering a domain name just for that aspect of an open source repo. With something like Discourse that could be like $20 / month + domain just for 1 instance of it. If you decide to use Discord or Slack as a side channel for casual chatting or feature requests then you're locked in there too and there's no persistence (at least not with Slack) or SEO discoverability. That and with any of the above solutions chances are folks will end up reporting bugs in those side channels which means someone needs to go back and write them up as proper issues, often times that'll be the repo owner. Plus now all users need to jump through hoops by registering on those external platforms to give a feature request on a project on GitHub. I hate the idea of vendor lock-in but at some point integrated platforms make sense because the alternative is worse. As a developer I really like having my code, CI, issues and a place to chat all in 1 spot. If GitHub dies, that's fine there's always Gitlab. If Gitlab dies, there's always Bitbucket but at this point the developer community would likely revolt and come up with a new solution.
    - TeMPOraL 6y ago
      > That's also true but where do you draw the line with vendor lock-in and convenience? Can I export all the data in a publicly documented, machine-digestible, patent-unencumbered format? Is the site helping, or at least not obstructing, alternative clients for interfacing with the feature? If the answer to any of these questions is "no", then it's vendor lock-in.
      - iFreilicht 6y ago
        Github issues can be exported to csv [1] and they have an extensive and well documented API. [2] So I'd say, GitHub isn't locked in as of now, they're quite open. But your definition is good, and it's probably a good idea to re-evaluate every now and then. [1]: https://stackoverflow.com/questions/41369365/how-can-i-export-github-issues-to-excel https://stackoverflow.com/questions/41369365/how-can-i-expor... [2]: https://docs.github.com/en/rest https://docs.github.com/en/rest
    - fomine3 6y ago
      Agreed. Just moving discussions to Slack is bad for discoverability.
  - onionisafruit 6y ago
    It seems like any non-trivial feature will increase vendor lock-in. Dark mode is the only recent GitHub feature that can’t be said to increase lock-in.
- varajelle 6y ago
  > I hope the Discussions feature becomes generally available soon. Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)
devmunchies 6y ago
Makes me think of having a single issue on a github repo for feature requests and anyone can dogpile onto it. If anyone opens a new issue with a feature request you direct to the other "feature request issue" and close their new issue. Keeps issue bloat under control and allows users to request features in the same place as the code.
- pseudalopex 6y ago
  Sounds like somewhere for feature requests and discussions to die. What's wrong with just tagging feature requests?
  - devmunchies 6y ago
    perception of neglected or under-resourced project from too many open issues. I don't like it and its not correlated but thats the realty.
TAForObvReasons 6y ago
NPM really exacerbated the problem with the npms.io ranking service. They rank searches like https://www.npmjs.com/search?q=pad%20string https://www.npmjs.com/search?q=pad%20string on metrics like "quality" and "maintenance". They track how many issues are open more than 7 days, more than 1 month and more than 1 year in order to make a judgment, so there's a strong incentive to aggressively close issues early
mook 6y ago
On (Mozilla's) bugzilla, feature requests (in local jargon, "RFE", request for enhancement) were filed on the same bug tracker and were indexed as bugs, too, long before GitHub existed. Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.
- skissane 6y ago
  I remember when I used to work for Oracle, and Oracle's internal home-grown bugtracker (BugDB) had both bugs and enhancement requests logged in it going back to the 1980s. (I actually tried to find the oldest record... the oldest one I could find was from something like 1984 or 1985, if I remember right.) And I know the PMs actually went through the enhancement requests the customers logged (I think it was once per a release cycle), and evaluated whether any of them were worthwhile to implement or not. So, in proprietary software, using a bug tracker to track feature requests is a lot older than Mozilla/Bugzilla.

by wott 6y ago

nickjj 6y ago

> Well, the problem is not some "open source culture", but GitHub. Github's specific open source culture, if you like. Agreed. But GitHub is also slowly fixing this. For example the "Discussions" beta feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions https://github.com/ImageMagick/ImageMagick/discussions. It's only available on a small subset of repos tho and it's something you can turn on and off at the repo level. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions https://github.com/nickjj/flask-db/discussions. I hope the Discussions feature becomes generally available soon.

wott 6y ago
Yes. On the other hand, the goal is also to increase the vendor lock-in, by providing everything inside their garden walls, so that people keep going further into giving up any side channel and into putting all their eggs into the same Github basket.
- nickjj 6y ago
  > On the other hand, the goal is also to increase the vendor lock-in, by providing everything inside their garden walls, so that people keep going further into giving up any side channel and into putting all their eggs into the same Github basket. That's also true but where do you draw the line with vendor lock-in and convenience? If you use Google's mailing list service then you're locked into Google. What if they decide to drop that like many other services in the past? If you use a self hosted forum / mailing list instead, the repo owner is on the hook for setting up and configuring a server along with potentially registering a domain name just for that aspect of an open source repo. With something like Discourse that could be like $20 / month + domain just for 1 instance of it. If you decide to use Discord or Slack as a side channel for casual chatting or feature requests then you're locked in there too and there's no persistence (at least not with Slack) or SEO discoverability. That and with any of the above solutions chances are folks will end up reporting bugs in those side channels which means someone needs to go back and write them up as proper issues, often times that'll be the repo owner. Plus now all users need to jump through hoops by registering on those external platforms to give a feature request on a project on GitHub. I hate the idea of vendor lock-in but at some point integrated platforms make sense because the alternative is worse. As a developer I really like having my code, CI, issues and a place to chat all in 1 spot. If GitHub dies, that's fine there's always Gitlab. If Gitlab dies, there's always Bitbucket but at this point the developer community would likely revolt and come up with a new solution.
  - TeMPOraL 6y ago
    > That's also true but where do you draw the line with vendor lock-in and convenience? Can I export all the data in a publicly documented, machine-digestible, patent-unencumbered format? Is the site helping, or at least not obstructing, alternative clients for interfacing with the feature? If the answer to any of these questions is "no", then it's vendor lock-in.
    - iFreilicht 6y ago
      Github issues can be exported to csv [1] and they have an extensive and well documented API. [2] So I'd say, GitHub isn't locked in as of now, they're quite open. But your definition is good, and it's probably a good idea to re-evaluate every now and then. [1]: https://stackoverflow.com/questions/41369365/how-can-i-export-github-issues-to-excel https://stackoverflow.com/questions/41369365/how-can-i-expor... [2]: https://docs.github.com/en/rest https://docs.github.com/en/rest
  - fomine3 6y ago
    Agreed. Just moving discussions to Slack is bad for discoverability.
- onionisafruit 6y ago
  It seems like any non-trivial feature will increase vendor lock-in. Dark mode is the only recent GitHub feature that can’t be said to increase lock-in.
varajelle 6y ago
> I hope the Discussions feature becomes generally available soon. Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)

devmunchies 6y ago

Makes me think of having a single issue on a github repo for feature requests and anyone can dogpile onto it. If anyone opens a new issue with a feature request you direct to the other "feature request issue" and close their new issue. Keeps issue bloat under control and allows users to request features in the same place as the code.

pseudalopex 6y ago
Sounds like somewhere for feature requests and discussions to die. What's wrong with just tagging feature requests?
- devmunchies 6y ago
  perception of neglected or under-resourced project from too many open issues. I don't like it and its not correlated but thats the realty.

TAForObvReasons 6y ago

NPM really exacerbated the problem with the npms.io ranking service. They rank searches like https://www.npmjs.com/search?q=pad%20string https://www.npmjs.com/search?q=pad%20string on metrics like "quality" and "maintenance". They track how many issues are open more than 7 days, more than 1 month and more than 1 year in order to make a judgment, so there's a strong incentive to aggressively close issues early

mook 6y ago

On (Mozilla's) bugzilla, feature requests (in local jargon, "RFE", request for enhancement) were filed on the same bug tracker and were indexed as bugs, too, long before GitHub existed. Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.

skissane 6y ago
I remember when I used to work for Oracle, and Oracle's internal home-grown bugtracker (BugDB) had both bugs and enhancement requests logged in it going back to the 1980s. (I actually tried to find the oldest record... the oldest one I could find was from something like 1984 or 1985, if I remember right.) And I know the PMs actually went through the enhancement requests the customers logged (I think it was once per a release cycle), and evaluated whether any of them were worthwhile to implement or not. So, in proprietary software, using a bug tracker to track feature requests is a lot older than Mozilla/Bugzilla.