[HN Gopher] GitHub Stale Bots - A False Economy
___________________________________________________________________
GitHub Stale Bots - A False Economy
Author : gitgud
Score : 268 points
Date : 2021-01-18 12:28 UTC (10 hours ago)
(HTM) web link (blog.benwinding.com)
(TXT) w3m dump (blog.benwinding.com)
| joshxyz wrote:
| Stale bots are stupid i wanna smack the face of whoever invented
| them.
|
| Those bots keep closing valid issues!
| patcon wrote:
| And old rant in their issue queue:
| https://github.com/probot/stale/pull/107#issuecomment-379021...
|
| > Thesis: Stalebot -- in dutiful service of _current_ human
| resource constraints -- feels like it unthinkingly prioritizes
| discard of _past_ contributors ' time resources, over the
| mobilization of new human resources.
|
| I've had a beef with Stale since early on. It's a very old-world
| view of solving the problem of open source capacity. A better
| tool would instead try to find and encourage new resources (new
| contributors), whereas stalebot drives them away, and so kinda
| cuts the project off at the knees
|
| imho, in the short-term, it rescues the cognitive and emotional
| resources of current contributors, but (in the long-term) drives
| future contributors away through promoting lack of care and by
| encouraging maintainers to not interact with them.
| baobabKoodaa wrote:
| I used to open GitHub issues to Gatsby to report bugs. Almost
| nothing was ever fixed and every few weeks I had to manually
| clickety-click to keep the issues alive because of the stale bot.
| Guess what I do now? I don't report bugs to Gatsby, and I
| recommend against using Gatsby in newer projects.
| tvanantwerp wrote:
| Sadly, I've had this same experience with Gatsby.
| Cthulhu_ wrote:
| My experience is different, back when I used it (about a year
| and a half ago last? Ish?), they seemed to have dedicated
| community management staff doing the rounds and making sure all
| issues were acknowledged, tagged, and addressed. Has that
| changed since then? At the time I found it a really welcoming
| and active community. I even got a T-shirt for contributing.
| baobabKoodaa wrote:
| I also found the community active and welcoming. I also got a
| t-shirt. All of my issues were tagged. Unfortunately they
| weren't fixed, and the stale bot kept marking them as stale.
| It seemed to me like Gatsby developers were focusing the
| majority of their time on writing "fun" new features rather
| than fixing all the sharp edges and broken pipes of the
| complicated pile of old features.
| wpietri wrote:
| That fits if we think about it in POSIWID terms: https://en
| .wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
|
| If the true goal of the devs is to do the fun first 25% of
| the work, then the signs that a particular job hasn't been
| finished are unwelcome. A stale-bot sweeps most problems
| under the rug and, as we see in the discussion here,
| discourages reporting in the first place. The numbers look
| better, the devs get to feel like things are under control,
| and they get to rush on to the next shiny thing.
|
| And perhaps it works one layer deeper, too. Their website's
| all about "fast, fast, fast"! They advertise the ability to
| "create a complete website in the time it usually takes to
| build a prototype". I would read a claim like that
| suspiciously: when I build prototypes, I leave out things
| that are important for sustainability. But the things I
| think are "finishing the job right" seem to others as
| tedious and uninteresting things to be skipped if possible.
| So perhaps the devs have found themselves an audience like
| themselves that are fine with a high level of brokenness as
| long as they get the feeling of moving forward quickly?
| z77dj3kl wrote:
| Yes, I've had a similar experience. Gatsby is a dumpster fire
| once you venture off the beaten path.
| sneak wrote:
| It's also spyware, transmitting your usage without consent:
|
| https://www.gatsbyjs.com/docs/telemetry/
| rgovostes wrote:
| "Spyware" has a specific meaning and shouldn't be applied
| to any instance of data collection you disagree with.
|
| That you can point to their documentation about their data
| collection practices, which are explained in concise
| English with opt-out instructions, and that this is
| apparently detailed to the user on install, strongly
| suggests Gatsby is not spyware.
|
| Telemetry can be very valuable to open source projects
| which have extremely limited resources. The Adium project
| used telemetry to decide when they could drop support for
| PowerPC processors and old versions of macOS[0]. Homebrew
| uses it to track which of its thousands of packages are the
| most problematic to install[1].
|
| 0: https://sparkle.adium.im/?year=2020&week=*&graph=bar
|
| 1: https://formulae.brew.sh/analytics/
| sneak wrote:
| Homebrew is also spyware.
|
| They transmit your unique identifier to Google every time
| you run brew, which effectively provides Google with your
| coarse location tracklog via client IP geolocation.
|
| Data collection like this that is done without the
| consent of the user is extremely unethical, rude, and in
| some jurisdictions actually illegal. The fact that the
| data they steal is useful to them is not relevant and
| your bringing it up is telling.
|
| It actually has nothing to do with whether or not I agree
| with it, and everything to do with whether or not they
| obtain consent to exfiltrate this information. Neither
| Homebrew nor Gatsby obtain the consent of the user to
| transmit their spying data.
| mrob wrote:
| Opt-out telemetry is spyware, regardless of how
| convenient you might find it to spy on your users without
| their consent. The only ethical telemetry is opt-in, such
| as the system Debian uses, where users are given the
| option to install the "popularity-contest" telemetry
| package during install, with the default being not
| installing.
| rightbyte wrote:
| > We track general usage details, including command
| invocation, build process status updates, performance
| measurements, and errors.
|
| Sounds like spyware to me to do that without opt-in.
| Projects that do that wont take your privacy seriously.
| madeofpalk wrote:
| Or, stay on the beaten path for too long and get "too big"
| and it turns into a dumpster fire.
| cheph wrote:
| Gatsby is probbably the worst static site generator that exists
| and I am not really sure what it brings to the table other than
| incredibly slow build times, pointless use of graphql (which
| falls apart quite quickly) and an over complicated framework
| which is difficult to customize and costly to maintain.
| jrv wrote:
| I like that I can write pretty much normal React in it, and
| that it has a lot of features and plugins. But I'm still a
| pretty casual user probably.
| madeofpalk wrote:
| Yes, I've seen the same problems from Gatsby and it wouldnt
| be my first choice, but I do really like it's use of GraphQL
| - i think it's a smart way to solve a problem that does exist
| for some use cases.
|
| I like Gatsby's createPage API that lets you programatically
| create pages from source data at any url, rather than the
| "traditional" approach of binding views to URL patterns. It's
| useful for some kinds of static sites that might have a
| radically different template or data source/model for
| multiple pages that fit the same URL pattern.
|
| Gatsby's use of GraphQL, which can be a pain especially as
| you scale larger, is nice how it lets you query just the
| fields you need, so your dehydrated data remains pretty
| minimal. It's something that I've struggle with when building
| a site with NextJS - I would have to set up and create my own
| GraphQL server.
|
| Gatsby is a weird one because it has these "advanced"
| features that really benefit larger sites (or sites with
| larger ambitions), but Gatsby really can't handle large sites
| or data.
| Cthulhu_ wrote:
| I found the GraphQL decision really works if you're
| combining multiple datasources. One example we built in
| practice is combining a CMS-as-a-service (Contentful,
| Prismic) and a webshop back-end as a service
| (Commercetools) to build rich product pages.
| madeofpalk wrote:
| Yeah, it can be really helpful when you want to combine
| multiple data types/sources into a single meta type to
| query multiple types with just a single graphql query.
| ljm wrote:
| It turns out that building a site in plain HTML, without
| fancy tools, isn't nearly as difficult as using stuff like
| gatsby once you get down to it.
|
| Hell, just throw in some PHP if you want dynamic bits and
| pieces. Your fancy netlify/cloudflare/vercel setup may not
| like it but your infinitely cheaper shared host/VPS provider
| will.
|
| If you still wanted static output, you could probably serve
| it locally and then let wget crawl it for you.
| icebraining wrote:
| > infinitely cheaper
|
| It's actually the opposite. Static site hosting is so much
| easier to optimize, that it costs just few cents a month,
| if anything at all (I never went beyond Netlify's free
| plan).
| madeofpalk wrote:
| > If you still wanted static output, you could probably
| serve it locally and then let wget crawl it for you.
|
| Here's the complexity part that tools try to solve.
| john-shaffer wrote:
| There are decoupled tools like https://statically.io/ to
| do this. One can have the straightforward builds of GP
| and still have good static site generation.
| krisgenre wrote:
| I've just started using Eleventy for our site. For someone
| completely new to this it was bit difficult to start but once
| off the ground have started to love it. The best thing is if
| any feature is missing you can quickly write a plugin in
| javascript.
| ghego1 wrote:
| If you are looking for an efficient static site builder try
| YASSB! [1]
|
| YASSB processes HTML, (S)CSS, JavaScript/TypeScript, JSX/TSX,
| JSON, MarkDown and many other files and combines them into
| beautiful static websites.
|
| I am the creator of YASSB, I'd love to hear what you think
| about it!
|
| [1] [https://yassb-foss.github.io/](https://yassb-
| foss.github.io/...
| ghego1 wrote:
| Link: https://yassb-foss.github.io/
| SkyPuncher wrote:
| I used Gatsby about 3 years ago and loved it. With that being
| said, I feel like it's grown well beyond it's useful value
| proposition for me.
|
| The biggest value was I could share a lot of components
| between my app and marketing site. Even though most of the
| marketing site was static content, Gatsby made it incredibly
| easy to introduce well integrated custom features.
|
| I never hit of the point of needing a full CMS (the site
| wasn't large enough), so it was great for my needs. Not sure
| why anyone would use it if they're going full CMS, though.
| cycomanic wrote:
| I can somewhat understand closing issues, but locking?! That's
| crazy I always understood looking to be about stopping unhealthy
| discussions etc. not to prevent bu reports.
|
| My main gripe with stale bots is that some have incredibly short
| timelimits attached to them. We were arguing about the
| expectations from users on maintainers to fix their issues
| immediately and I was strongly arguing that users can expect oss
| maintainers who are not compensated for their work to just jump.
|
| But there is also the other side to it, if I report a bug and the
| maintainer gets to it and ask for some more information (sometime
| quite extensive) to close the bug because I didn't reply within a
| week. I also have a live outside of reporting bugs.
| pingiun wrote:
| IMO NixOS has the right stalebot settings[0]. It was discussed
| thouroughly in the RFC, as to choose the right information text
| and other actions by the bot. For example, the bot will only mark
| the issue/PR as stale and will never close the issue or lock it.
| Issues are only ever closed by humans.
|
| The information text they came up with is quite a bit longer than
| the ansible one[1]. I think this is a very important point when
| adding such a bot, otherwise the user will be left helpless.
|
| [0]: https://github.com/NixOS/rfcs/pull/51
|
| [1]: https://github.com/NixOS/nixpkgs/pull/92254
| iFreilicht wrote:
| Oh wow, that is very well worded! Not only do they explain why
| issues have to be marked as stale and how the reporter can
| remove the label. It's also friendly and appreciates that the
| user made the effort to create an issue in the first place and
| helps them do more to get attention to the issue.
| jrockway wrote:
| If you open a bug, you are saying "here's a problem I found
| that's not important enough to me to spend time fixing". The
| auto-close bot says "we agree that this is not important enough
| to fix."
|
| If you're paying for a support contract and an auto-close bot is
| closing all your issues, you should stop paying for the support
| contract, though.
| pseudalopex wrote:
| Here's a problem I found I don't know how to fix.
|
| Here's a problem I found and how I would fix it. Does it sound
| good to you?
|
| Here's a problem I found. It's important enough for me to fix
| but I can only work on it sporadically.
|
| Here's a problem I found. My employer owns everything I write.
|
| Here's a problem I found. I'm not a programmer.
| mook wrote:
| Sometimes external contributors do not have the correct power
| to fix the issues they open; mainly that means the maintainer
| needs to take some decision (and possibly instruct the issue
| creator to make a PR). That is, the amount of effort the
| external person needs to spend time to fix it is "become the
| maintainer".
| habosa wrote:
| Hmmm there are two things here:
|
| 1) Marking inactive issues as stale and eventually closing them
| automatically.
|
| 2) Locking old closed issues so they don't get comments.
|
| Many bots do these things and do them badly. I maintain a bot
| that I think does (1) better.
|
| The key is that an issue is only stale if a maintainer has asked
| a question of the person who filed the issue and that person is
| not responding. That's the only condition.
|
| An issue is NOT stale just because there's been no activity
| recently. That could just mean the maintainer is on vacation or
| has other things to do. Repos which have bots that close issues
| for lack of maintainer action are getting off to easy.
|
| I'm a bit more torn about locking old issues. On the one hand it
| saves you from a lot of low-value "me too" spam comments and lets
| you focus on only open issues. On the other hand you will miss
| legitimate regressions.
| jsmith45 wrote:
| >The key is that an issue is only stale if a maintainer has
| asked a question of the person who filed the issue and that
| person is not responding. That's the only condition.
|
| The possible issue with that criteria in general is that it
| need not actually be the original poster who replies with the
| needed details. Another user with the same problem could supply
| the needed details as well.
|
| A different user supplying the answer is especially common on
| widespread issues that the maintainers are having problems
| tracking down. For example, it might be that the problem only
| reproduces on a certain version of a specific distro, or only
| if certain kernel configuration options are used. Those sorts
| of issues can be hard for the maintainer to discover, but might
| be easier for impacted users to locate.
|
| You may well have stuff in place to handle this, but thought it
| was worth pointing out for completeness sake.
| strenholme wrote:
| I think it's irresponsible to let bugs languish like this. The
| way I handle bug reports is to say "Hey, look, I just can't fix
| this right now because I'm working full time and don't know when
| I'll be able to get around to fixing this without getting paid
| for my work." E.g. https://github.com/samboy/MaraDNS/issues/84
|
| I can see why a lot of people don't do that: It's a little rude,
| and there's a small but significant chance it'll become a flame
| war. I have only once had someone get rude in a ticket when I
| told them "That's not a bug report, but a support issue"; I ended
| up deleting the ticket. GitHub also allows you to edit or delete
| other people's comments in your tickets, as well as locking the
| conversation.
| m3nu wrote:
| It's a tool like every other. Can be used in a good or bad way.
|
| I also use the stale bot, but with many labels excluded. If an
| issue has a proper label, it will stay open forever. If it's just
| a question or support request, it will be closed after 2 months.
|
| This prevents me from reviewing too many irrelevant and outdated
| issues, where the reporter moved on a long time ago.
| al2o3cr wrote:
| I don't agree with the author's premise - the reason that users
| create duplicate issues isn't completely (or even mostly) because
| they can't add comments onto old issues.
|
| If it _was_, then surely the typical duplicate issue would start
| with "Reopening #1234" since the user has literally looked at
| that page already.
| spoiler wrote:
| I've had to do that a few times in the Kubernetes family of
| repos, because of fejita bot. I'm sure I've done it a couple of
| other times in less popular repos too.
| bluehatbrit wrote:
| From brief conversations with the team behind the GitHub stale
| bot, the original idea was clearing up tickets where the user
| didn't respond to the maintainer. I don't think this is what
| happens usually though. Sadly most cases I see are the same as
| the angular case in this article.
|
| I made an issue suggesting tickets not be marked as stale if
| they've not had a maintainer comment yet. As you can imagine, the
| stale bot installed on the repo itself kept trying to close it
| due to it being "stale". After several months the irony wore off
| and I let it get closed.
| tobr wrote:
| Ideally an issue is not a conversation between a "user" and a
| "maintainer" though, but a place for a community to coordinate
| around a bug or feature request. I wouldn't open an issue
| unless I thought someone more than me might find the topic
| useful, and so I also don't feel like I have an obligation to
| participate in the conversation - after all, it's not about me,
| but about ways to improve the code. I find it somewhat
| offensive when people post to request support on something that
| can't reasonably be useful to anyone else.
| cdubzzz wrote:
| > Ideally an issue is not a conversation between a "user" and
| a "maintainer" though, but a place for a community to
| coordinate around a bug or feature request.
|
| What do you mean by this? A bug report or feature request
| will generally come from a "user" and is likely of interest
| to a "maintainer". What should the two do if not converse?
| Neither the maintainer nor the user really knows whether or
| not an issue will be "reasonably useful to anyone else"
| without talking about it.
| zeckalpha wrote:
| Those personas are not mutually exclusive. Projects that
| divide the two don't tend to be successful, leading to
| maintainer burnout, and autoclosed issues.
| geerlingguy wrote:
| Sadly it seems about 90% of people don't have your mentality
| :(
|
| And the worse fact is, in terms of sponsorships the 10% of
| people who are more helpful in the issue queues and are
| already helping make maintainers lives easier are often the
| ones who consider sponsorship or other means of support.
|
| That's great, but it's disheartening that the people who feel
| entitled to an answer about a support question are almost
| 100x less likely to show any kind of support to open source
| projects (monetary or otherwise).
| wolco5 wrote:
| This makes total sense. 10% of your users are superfans
| they read / understand everything you publish. They are so
| into it they give support (word of mouth, helping onboard
| others, bug patches, they will test alpha builds and give
| money/time where possible).
|
| 90% of users don't understand your product as well. They
| haven't totally bought in. They will need more
| support/handholding in order to convert. People are trying
| to get your product to work for their situation and if they
| can't 90% will go away and 10% will ask (usually dumb
| questions).
|
| Your unhappy with the 10% who can't get it working but want
| your product to work enough to bother to ask?
|
| I guess you can feel that way. Those 10% do represent an
| opportunity to get a group of people who want to use your
| product to onboard. The ones who tried and failed and never
| asked a question will probably never come back. If you
| ultimately want more support you are going to need to
| convert this group (or invest more time in advertising
| hoping to get more superusers/fanboys)
| rapnie wrote:
| A not-stale bot is needed here, that reacts on stale
| notifications. /s
| abathur wrote:
| Right. In a very different context, I implemented something a
| lot like this for a game's bug tracker, using assignments.
|
| Ask the player to clarify something, assign the bug to
| feedback. If no one ever comments to save it, it'll get nudged
| a few times before it's automatically dismissed.
|
| It was a godsend, because it got those issues out of the triage
| queue and didn't return them until they were actionable again.
| dathinab wrote:
| The problem is it had become not uncommon that any kind of
| stale issues get automatically closed not just such which
| "need feedback".
|
| I.e. you make a bug report, it get's verified but is low
| priority. Because of higher priority issues the maintainers
| do not yet work on it. The issues becomes stale and now the
| maintainers will _never_ work on it unless you always prevent
| stall or reopen a new issue.
|
| And sometimes there are issues which can not be resolved but
| still are issues (e.g. (for now) unsolvable bug) IMHO such
| issue should stay open even if there will not be any
| work/improvement on them for maybe years.
| abathur wrote:
| Yes, this is why I'm describing a design that focuses on
| just what needs feedback.
| chrismorgan wrote:
| I'm bemused that this complaint is almost entirely about
| _locking_ issues. Most I've ever had the misfortune to encounter
| haven't been _locking_ issues, just _closing_ them, which isn't
| quite as bad (but almost).
|
| I loathe, despise and abominate the GitHub bot with the name
| "stale" and think it should be discontinued with prejudice. I
| have never had a positive experience with it, and genuinely
| cannot imagine _any_ scenario in which it would provide more
| value than the harm it causes.
|
| What of other stale bots that are more nuanced or that provide
| more meaningful descriptions of what and why? Well, I can think
| of one or two interactions over the years that seemed more
| reasonable (e.g. TypeScript's "it's been a while, there aren't
| ten votes and it hasn't been accepted, probably nothing's going
| to happen, speak now or it'll be closed"), but even they still
| cause substantial harm (duplicates, _& c._) because GitHub's
| search defaults to excluding closed issues. But most of them
| should definitely be killed with fire.
|
| Ooh, ooh! If we're ranting about issue management systems, here's
| another of mine: free-form text fields with templates. You ever
| tried searching for a word that happens to appear in the
| template? Yeah, it's completely useless. I guess this one could
| be mitigated by a more intelligent indexer that filtered out the
| template first.
| TonyTrapp wrote:
| I'm completely with you on the free-form text fields. How could
| we end up with such an unstructured way of filing issues as the
| default?
| ponyous wrote:
| Stale bots caused me to waste weeks on libraries that were
| garbage. The moment I see stalebot on repository I start to think
| the company is just doing open source so they look cool for new
| hires. Please stop using stale bots.
| pwdisswordfish5 wrote:
| It comes with the territory; aiding you in the quest for cool
| is one of GitHub's only value propositions. Because it's
| certainly not about productivity. People substitute having a
| conspicuous social presence for getting work done. Looking
| around at what everyone else is doing and copying that without
| thinking about what value it brings. Retroactively insisting
| they have value with subjective and unfalsifiable claims. It's
| all part of the tao of GitHub.
| ddevault wrote:
| This mostly happens, I think, on projects which don't care about
| bugs from the general public. This includes Angular, but also Go
| and Firefox, for example. Their teams are working at a level too
| far detached from the general public to care, and they mostly
| focus on their internal priorities instead. And that's a valid
| approach to managing your FOSS project - it comes with no express
| or implied warranty of merchantability or fitness for a
| particular purpose, in all caps no less.
|
| If a bug report does not immediately catch the attention of the
| maintainers under such circumstances, it's unlikely to do so
| later on. The maintainers don't care about dupes, because they
| didn't care about the original either. They're going to have tens
| of thousands of tickets no matter what.
|
| Of course, if you find yourself at the wrong end of this process,
| the best way to get attention for your bug report is to attach a
| patch.
| swills wrote:
| To me, this is exactly right and summarizes the situation well.
|
| Maintainers actions demonstrate their priorities, which are
| driven by their funding rather than community needs. This is
| the difference between community driven projects and corporate
| driven ones (even if the corporate drive is indirect via
| funding). Writing a patch is often the only path forward and
| often even that is ignored or nit picked until people move on.
| cdubzzz wrote:
| This is a solid explanation. It also makes me wonder, why even
| use GitHub at a certain point? It seems like GH is a one-size-
| fits-all approach and the primary reason to use it is to get
| _more_ issue, PRs, etc. in your project. But once you hit a
| certain scale, maybe it's time to move to a more customizable
| solution?
| ddevault wrote:
| Beats me. This is why SourceHut lets you pick and choose any
| number of repos, bug trackers, mailing lists, etc, including
| zero, to associate with a project. I suspect that some
| projects just use GH to shut the peanut gallery up; a lot of
| people will demand that any large-ish project moves to GH if
| they aren't already there. That certainly seems like why
| Golang did it, for one.
| strenholme wrote:
| One reason for the demand to move to GitHub is because it
| makes it easier to find software to solve a problem which
| is actually open source software if everyone has a GitHub
| mirror.
|
| Searching for "Open source foo" often times results in a
| bad search results: https://www.google.com/search?query=Ope
| n+Source+WOFF+generat... doesn't link to the open source
| reference C language WOFF generator but
| https://github.com/search?l=C&q=WOFF&type=Repositories does
| find it.
| ddevault wrote:
| Your case is a bit weird. You're looking for a specific
| niche codebase, whose authoratative source has
| disappeared, and end up at a non-authoratiative archive.
| That's Google on hard mode. If you knew you wanted the
| reference converter, a more specific Google search would
| have worked:
|
| https://www.google.com/search?q=ttf2+to+woff+reference+co
| nve...
|
| A more in-depth research effort into the solution space
| also turned up things like FontForge and
| github.com/google/woff2, neither of which showed up in
| the GitHub results, but depending on your use-case are
| likely to have been compelling options.
|
| I think it's more important to use FOSS infrastructure
| for FOSS projects than it is for those projects to turn
| up in a search result. I also think that projects can and
| should market themselves in a manner which extends beyond
| appearing in search results. However, I do acknowledge
| that GitHub search can be useful. I have been thinking
| about letting you link up repositories hosted on not-
| sr.ht for your sr.ht projects, which are indexed here:
|
| https://sr.ht/projects
|
| So you could, for example, have a GitHub repository, a
| GitLab repository, and a sr.ht mailing list, all under
| the same project, indexed in one place. This would go a
| long way towards establishing a single list of FOSS
| projects. It would be centralized at first, but I have
| also been thinking about using RSS to federate the
| project list across many independent sr.ht installations:
| centralization gone.
| 8K832d7tNmiQ wrote:
| Isn't this the reason why Github Discussion exists? To basically
| become an internal StackOverflow for the repo?
| ocdtrekkie wrote:
| I think there's a difference between "languishing issue that
| hasn't gotten fixed" and a discussion. Both have a purpose, and
| they are separate purposes.
| dathinab wrote:
| I can only agree with that.
|
| I have had been involved in to many "stale" but neither fixed nor
| forgotten issues which would have become very cumbersome if a
| stale bot was involved.
|
| Common reasons for "staleness" include:
|
| - blocked on other issues
|
| - blocked on external dependencies
|
| - blocked because no one has currently time to fix the issue
| because there are many other high or very high priority issues.
| This doesn't mean it has low priority, just not high/very high
| priority.
|
| - feature requests which the author agreed to should be
| implemented, but neither the maintainer nor the issuer has
| currently time to work on.
|
| - feature requests which are braking changes and as such will
| only included if a new version is made
|
| - bugs with low priority if there are higher priority things
|
| Sure you can work around this by using many labels and making the
| stale bot label aware e.g.:
|
| - label contains "blocked" => do not stale close
|
| - label contains "bug" => do not stale close (and only assign bug
| if issuer provides the necessary information)
|
| - label contains "next-version" => do not stale
|
| - label contains "...." => do not stale
|
| But that seems somewhat pointless for the large majority of
| crates.
|
| Furthermore I believe stale bots come to some degree from the
| (IMHO) unrealistic idea that the amount of open issues, issue
| closing time and issues staleness indicate how health a project
| is.
|
| But the moment you have feature request issues or "will be fixed
| in next release as braking change" this metrics fall apart
| completely.
|
| Similar some software projects get a lot of spam issues (often an
| indication that a popular project probably needs some
| improvements of documentation or UX aspects). For this it can
| sometimes be reasonable to have stale bot _if_ it doesn 't act on
| certain labels IMHO.
| cute_boi wrote:
| I used to report bugs but now I don't report any bugs. Many
| developer thinks that I am reporting issue is adding work on
| them. I have faced such issue on Gatsby and VScode where they
| just lock issue.
| djohnston wrote:
| I am currently inundated with other people's bots making
| automatic tasks / warnings etc, totally overwhelming everyone
| around them. The only way to cope with the noise is to... build a
| bot :)
| timdaub wrote:
| On some projects, I took the time to write a nice issue about a
| bug I sometimes even went so far as to debugging it in the
| dependencies code.
|
| I feel let down when a bot comes along and closes this issue.
| Maybe it's stale, but the issues sometimes remain...
| habitue wrote:
| Assuming it's not locking an issue, I really like stalebots for
| internal projects. There are lots of things that just become moot
| after a while because things change so rapidly. If you run into
| the problem again, it's always easy to reopen the issue or refer
| to the old one, usually with more up to date context.
|
| It also means if you sort issues by oldest and is:open, you get
| longstanding problems rather than "things we were worried about 2
| years ago, but were never important enough to fix or close".
| wraptile wrote:
| There's also this discrimination in open source culture where's
| "a lot of issues" are often interpreted as "low quality package".
|
| I'd often hear people complain in the lines of "it's has a lot of
| stars and constant commits but there's over 100 issues so we
| might want to avoid it". Which really rarely correlates. Maybe
| the term "issues" is just too loaded, especially when often those
| are feature suggestions or even information/how-to tickets - not
| exclusively bugs or "issues".
| yhoiseth wrote:
| Good point. "Observation" is a better term in my experience.
| wott wrote:
| 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.
| mook wrote:
| 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 wrote:
| 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 the proprietary software world, using a bug tracker
| to track feature requests is a lot older than
| Mozilla/Bugzilla.
| nickjj wrote:
| > 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.
|
| 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.
|
| I hope the Discussions feature becomes generally available
| soon.
| varajelle wrote:
| > 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)
| wott wrote:
| 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.
| onionisafruit wrote:
| 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.
| nickjj wrote:
| > 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 wrote:
| > _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 wrote:
| 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-expor... [2]: https://docs.github.com/en/rest
| TAForObvReasons wrote:
| NPM really exacerbated the problem with the npms.io ranking
| service. They rank searches like
| 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
| devmunchies wrote:
| 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 wrote:
| Sounds like somewhere for feature requests and discussions
| to die.
|
| What's wrong with just tagging feature requests?
| trinovantes wrote:
| GitHub's generous free plans and accessible UI, especially in
| recent years, has removed a lot of the barriers that
| traditionally prevented many people from participating in open
| source projects. Consequently, this also resulted in a lot more
| noise on GitHub projects vs projects managed via mailing lists
| where bug reports are more concise and maintainers are more
| receptive (at least from my experience with LLVM).
|
| I think we're still in a transitional period where nobody really
| knows how to properly run large scale open source projects with
| low/no barriers to entry. Even well-funded projects repos like
| Typescript, VSCode, React receive more issues than they can
| close. Stale bot is not perfect but some automation is definitely
| required for these popular repositories. I suspect some barrier
| to entry may also required for a healthy repository to filter out
| the noise e.g. mandatory repository that reproduces the bug.
| WesolyKubeczek wrote:
| Really makes me wish we go back to mailing lists.
| intellix wrote:
| Massively agree. Also hate repositories that have issue templates
| that ask the same reworded question. I typically start writing it
| out and then just give up cause I can't think of how to answer
| the same question without just copy/pasting. You still get the
| typical "how can fix, not work?" issues so why overdo it? Should
| be simply:
|
| 1) What's wrong? 2) What's correct? 3) Reproduction
| pas wrote:
| It's (probably? totally!) arrogance, but usually I delete the
| questions from the template that have already been answered by
| what I wrote.
|
| In my experience the templates are for those who are simply so
| new to "open source", bug reporting, programming/software-
| development, GitHub and this amazing Internet thing, that they
| really benefit from going through it. (Sure, alas many people
| are inexperienced and doesn't read the templates ... :D)
| skissane wrote:
| I submitted a PR to make a tiny improvement to the libuv
| documentation... [0] and the stale bot wants to close it on me.
|
| I think closing PRs as stale is particularly annoying.
|
| [0] https://github.com/libuv/libuv/pull/3076
| prepend wrote:
| I've run into this on a few projects where PMs want to close all
| issues. Oddly there's no external metric on this, it's just some
| internal driver.
|
| It would result in closing old or low priority items rather than
| leaving them. It would also result in things not fixed being
| closed.
|
| It was a surreal conversation where I asked how they knew my
| issue was resolved without asking me, the person who submitted
| it. The PM said "what do you mean, we closed it. It's closed."
| And it took time to explain the difference between thinking it's
| done and properly confirming it's done.
|
| I find the most frustrating as a user is "closed, won't fix" as
| for OSS projects someone could eventually submit a fix.
|
| Closing "stale" issues is vanity tidying that's not necessary in
| a digital, "free" world.
|
| I think the fix for this is to look at the "unaddressed" metric
| to include any closed issues that weren't resolved. A high number
| of stale issues closed is a negative metric for a project. But a
| high number of lingering issues isn't so bad.
| nicbou wrote:
| Public ISSUES are important, because they measure the need for
| a feature. An important issue will generate more noise, and
| that indicates a lot of people struggle with it. "Me too" is a
| valuable metric, as is additional reproduction information from
| other users. User requirements are not final, so the answers to
| it should not be.
|
| On the other hand, stale TICKETS make it difficult to get an
| overview of the project and its priorities. Actually important
| issues can get lost in a sea of wishes. You can't have the team
| vote on the priority of 400+ tickets with no description, no
| justification, and no owner. Those tickets just sink to the
| bottom of the backlog, never to be seen again. On occasion,
| they're actually important, but hard to notice amid the 400
| other tickets.
|
| I always liked Kanban, because the to-do column is sorted. You
| can only sort a list by going through every item.
|
| When I was the agile whip, I always pushed for separate
| "triage" and "to do" tickets. The former is a bucket of wishes
| and stream-of-consciousness tickets. The latter is for tasks we
| understand and commit to. Our backlog refinement sessions
| cleaned the triage column, then sorted the to do column.
| prepend wrote:
| Issues can be tagged. So if there's a sea of wishes just tag
| them to reduce confusion and let people know they are low
| priority.
|
| Also, I don't have much of an issue with closing low quality
| issues, but if a user writes up a good issue and it is stale
| due to low priority, or not enough resources, or whatnot
| that's a different story.
|
| I also find it really easy to sort high priority issues
| amongst 400 because there are comments, likes, and activity
| on issues. So there's multiple ways for me to understand what
| it means.
| yoz-y wrote:
| A won't fix might make sense if the issue is a feature request
| that goes against the program philosophy. In that case forking
| the repo makes more sense.
|
| I wholeheartedly agree that closing issues just because they
| are old is a terrible practice. It's also why I have stopped
| sending radars. No point of doing work for somebody else if it
| just generates even more work for me.
| pas wrote:
| I have no problem with closing them for bugs, because in a
| few major versions usually the software changes sufficiently
| to have a good chance of that original bug report simply
| being obsolete (not reproducible, log/debug output not useful
| anymore, architecture changes, GUI changes, client
| software/driver changes, kernel changes, etc.)
|
| But in case of a feature request, where the project
| maintainer agreed it's a long term goal, a bot closing it is
| just noise, which IMHO discourages useful/insightful
| comments.
| yoz-y wrote:
| I don't think it's justified for bugs either. At least it
| should be opt-in per bug. It can hide especially sinister
| bugs that happen only in an uncommon case.
|
| This assumes a list of bugs that are actually reproductible
| bugs not an unfiltered feedback from the clients.
| lucideer wrote:
| I'm so glad someone's written this. I've been arguing this point
| on individual tickets for quite some time, and have yet to see
| anyone who agrees with me. I thought I was the only one.
| pferde wrote:
| Oh, you're far from the only one. It's just most of us just
| quietly shrug and move away from any project that does this.
| Life is too short, we should spend our time where it's valued.
| lathiat wrote:
| I guess there are some that close issues and others that lock
| them.
|
| I've always thought even the auto close bots suck but for a
| different reason than your thread locking example. That seems
| particularly terrible.
| necovek wrote:
| Indeed, I've never seen auto-lock bots on bug trackers before:
| this is terrible.
|
| I am fine with auto-close because they can indicate reality if
| they are closed with a WONTFIX status: nobody will work on
| fixing this. As opposed to eg OBSOLETE status which is not
| necessarily reality.
|
| If there is no explicit comment indicating how the project
| doesn't even want this, it is still an invitation for someone
| else to solve it themselves (for a free software project).
| aetherspawn wrote:
| Makes me hate Angular when I see my old, unsolved, tickets get
| locked with 100+ upvotes and comments.
| Aissen wrote:
| The ansible community does that too, and it's a pain. Instead of
| locking issues, they should be auto-transformed into a
| forum/community post, letting users discuss them if they want,
| and coordinate opening a new issue if necessary.
| thih9 wrote:
| I like this idea; especially from the point of view of future
| visitors, having a link that directs somewhere relevant is much
| more helpful than the "this issue is now closed" dead end.
| geerlingguy wrote:
| I've argued constantly against the locking of old issues, sadly
| I've lost that battle.
|
| Locking issues is hostile to the user experience, especially
| for issues that could be deemed as bug reports and where users
| could still collaborate among themselves in the closed issue.
| ROARosen wrote:
| I never understood why Github needs to 'lock' the stale issues.
| Isn't it possible to just 'mark' stale issues as being just that.
| What's the point of 'locking'?
| geerlingguy wrote:
| By default the stale bot does not lock issues. And you can
| configure it to mark stale, then either close or not close the
| issue.
| ROARosen wrote:
| OK let me rephrase that. Why do maintainers choose to lock
| issues as as opposed to just marking them?
| Dumbdo wrote:
| I assume they do that do avoid comments on old issues. If
| they are already using bots like that they are probably
| barely able to respond to new issues, so comments on old
| issues will never be read anyways. By forcing users to open
| new issues, it increases the chance for replies.
|
| That's at least what I understood from bigger repositories.
| It's not great and most maintainers are aware of the
| several shortcomings of that practive, but especially in
| huge repositories there are so many new (and sometimes low
| effort) issues daily that some maintainers are simply
| overwhelmed.
| anonymousab wrote:
| The pessimistic/realist view is that issues are sometimes
| ignored because, though they may actually be quite
| important, they are a pain to deal with or the maintainer
| of contributors just don't want to think about them.
|
| A matter of "out of sight, out of mind" but with the
| benefit of being able to instantly close off new issues
| without begetting discussion by marking them as a duplicate
| of the old locked and closed issue. A roundabout and
| obfuscated form of the "closed: wontfix/not interested"
| patterns of yore.
|
| Of course that's not the main or majority reason, but it is
| there. And it is fair.
| zimbatm wrote:
| Some people don't care and necro old threads, just to get
| the attention. They assume that it's worth pinging all the
| people involved in that thread, just in case somebody might
| know about their vaguely-relevant issue. After a while it
| becomes too tiresome and some maintainers decide that it's
| worth closing old threads.
| TeMPOraL wrote:
| Never understood the disdain for "necroposting" - neither
| here, nor in general in on-line discussions. Yes, posting
| in an old thread will bump it up to the top of the queue
| - _that 's the whole point_. The alternative is... to
| start a new thread on the same topic, which now has no
| context and will lead to pointless re-treading of the
| same paths.
| derefr wrote:
| * Sometimes there's already a newer, still-alive thread
| on the same subject (usually created by someone who
| didn't know there was already a thread on the subject,
| but sometimes created by someone who "wanted to avoid
| necroposting" and so intentionally created a new thread.)
| You shouldn't be posting in thread 1 about topic X, if
| you could instead be posting in thread N about topic X.
|
| * The older thread probably has a bunch of context given
| within it that's no longer relevant, and will just
| confuse the people trying to comment in the thread years
| later (e.g. requirements that are no longer valid or are
| already satisfied; requests/advice given in terms of
| architecture that's been refactored away from, or tooling
| that no longer exists; etc.) These threads are
| essentially "rotten" -- only of value to a cultural
| anthropologist, not for driving present goals. Better to
| avoid reviving such a "rotten" thread, and instead to
| create a new thread on the same subject, where you can
| provide a fresh context that doesn't conflict with the
| previous "rotten" context.
|
| IMHO, if comment/forum systems had richer semantics, the
| ideal would be to have "threads of threads" (meta-
| threads?), where repeated discussions on the same topic
| exist both as distinct threads, but also viewed in the
| context of a larger ongoing meta-thread (sort of like
| threads within a channel on Slack, but where the
| "channel" is still just one discussion. Maybe closer to a
| "user story" issue-tree-node in Jira, that has individual
| issues nested below it.)
|
| As it is, frequently maintainers use some microformat or
| issue-tracker annotation to mark new issues as dups of
| old issues as a reason for closing them. (But I'd
| honestly suggest that that's backward: usually, the old
| issue is "rotten"; so a new issue _should_ be allowed on
| the same topic; and moderators of the forum should go
| back to old, "rotten" issues and mark them as dups of
| the new issue, to allow people who find the old issue to
| follow the link to see the newer discussion on the same
| topic.)
| im3w1l wrote:
| The question for me is "do I want people to read through
| all this old content or not? is it relevant context or
| suffocating baggage?". If it's somewhere in between, a
| middle road option is to create a new thread but link the
| old one.
| raziel2p wrote:
| Most likely because "me too" or "any update on this?" type
| comments are extremely common.
| deathanatos wrote:
| ...perhaps if Github had a way to indicate directly on
| the bug that it affects you too. (And yes, most of the
| community is using the "thumbs-up" on the original issue
| to indicate that. That's a workaround for a missing
| feature, not a feature.)
| suprfsat wrote:
| All of buganizer, monorail, launchpad have a way to
| indicate that a bug affects you too. Launchpad literally
| has a button that says "this bug affects me".
|
| People simply act obnoxious and entitled for its own
| sake.
| joncrane wrote:
| Closing and locking are two different things.
| codebeaker wrote:
| The post solely looks at open source products, and for the
| author's example case (the Angular repository) it may be valid
| criticism.
|
| For internal repositories we find this to be really valuable in
| my company, the odd duplicated branch (when we couldn't get
| through CI for some reason, but recreating the branch) for
| whatever reason will be garbage collected, and all those
| `[CHORE]` branches people quickly hacked up without following our
| issue tracking process will be GC'ed too, if not handled.
|
| We run our (home made, with GitHub Actions, actually) bot in two
| stages, 30 days without activity, they get a label and a comment
| "stale, will be closed in 5 days, remove the stale label to
| prevent this", and then closure.
|
| This works great, except when people take extended vacation, or
| happen to switch between teams with WIP branches that are
| unmerged, but because Git never really loses anything, we've
| never lost work this way,we just benefit from easier summaries
| when looking for PRs to review, and having better metrics about
| mean time to merge, and other factors.
| necovek wrote:
| Note that even you are not auto-locking, but only auto-closing
| tickets.
| geerlingguy wrote:
| There's a huge difference between closing and locking issues.
|
| If you close an issue, people can still leave follow-up comments,
| and the issue can be re-opened if warranted. Some of the best
| issues on GitHub are closed issues where people have come in
| months or years after the fact and left useful additional
| information.
|
| Locking an issue leads to tons of duplication, annoying UX, and
| an overall hostile experience. In the 10,000+ issues I've managed
| on my own repos over the years, I've locked a grand total of ONE
| issues and that was just due to some borderline harassment
| (though unintended) that was going on long after useful discourse
| was over.
| [deleted]
| intellix wrote:
| Yep. I also like to leave a paper trail for myself when I'm
| having a similar issue. I'll typically leave information like
| workarounds/patches or explain how I ended up there
| Hackbraten wrote:
| Some projects use issues to represent maintainer work items.
|
| So if no maintainer plans to work on something, why not close the
| issue? It can be reopened anytime.
|
| Locking is a whole different thing because it prevents people
| from commenting. In closed issues, commenting is allowed though.
|
| I think closing an issue with a "thanks, we don't plan to work on
| this anytime soon but PRs are welcome" shouldn't be frowned upon.
| ocdtrekkie wrote:
| I disagree heavily because closed issues are less visible. An
| unresolved issue may be notable for other users to see and
| communicate about, a closed issue should be "done with". Either
| it is invalid or it is addressed or fixed.
|
| I'd argue developers who use the issues list as a personal todo
| list are using issues incorrectly.
| Hackbraten wrote:
| > I'd argue developers who use the issues list as a personal
| todo list are using issues incorrectly.
|
| If that method helps maintainers run their projects
| efficiently, why would you call it incorrect?
| ocdtrekkie wrote:
| Because it is user hostile. Even if it is helpful for them,
| if it hurts their users, they probably should be doing
| something else.
|
| If you hate your users, why open source at all?
| Hackbraten wrote:
| > it hurts their users
|
| Please help me understand why you think it hurts users.
| Hackbraten wrote:
| > I disagree heavily because closed issues are less visible.
|
| It takes one single extra click to include closed issues in a
| search. As a user/contributor, I'd figure that's a rather
| small price to pay, given that it helps maintainers handle
| their workload.
| ocdtrekkie wrote:
| Sure, but now you're diving through an incredibly thick
| soup: Some of those issues might have been resolved/fixed,
| as closed issues should be. Others might be current issues
| obscured because the maintainer hates their users and
| closes issues that are not resolved. Instead of having a
| clear marker on whether or not an issue is still a problem
| or not, you have to read the full text of every one.
|
| It literally makes "issues" worthless as a tool for anyone
| but the one dude who has it in their head to do things
| focused solely on themselves and their needs and ignorant
| to everyone else.
|
| And frankly: Issues is a terrible way to manage your own
| workload, so doing it harms you _and_ everyone else at the
| same time. Use a project board or something, there are
| tools designed for this. Even on GitHub itself, labels and
| milestones and projects all can be employed to enable
| reasonable project management... closing user issues
| without resolving them is definitely not one of them.
| _Seriously, don 't do this._
| Hackbraten wrote:
| > having a clear marker on whether or not an issue is
| still a problem or not
|
| Is that a goal worth pursuing? What problem would be
| solved by having such a "clear marker"?
|
| > you have to read the full text of every one.
|
| Even if "closed" meant "marked resolved", wouldn't you
| (mostly) still have to read the solution to get any
| benefit from it?
| ocdtrekkie wrote:
| So, let's say your project has a bug in a feature.
|
| Someone opened an issue about it, maybe even documented a
| workaround of some sort, but you didn't have time to fix
| it, and then you closed it because you hate your users.
| Now I experience the issue. First place I'm going to look
| is _open GitHub issues_. I find nothing, suffer more
| self-troubleshooting, maybe file an issue myself, because
| why would I look at closed issues... closed issues are
| generally resolved! I end up annoying you with an extra
| issue report, and wasting hours of my time. If I 'm lucky
| enough I happen to run a search that shows me the other
| user's report, I have no way to reopen the issue. I can
| maybe "me too" it, but given that you closed it already,
| I know you don't care.
|
| More than likely, after wasting a bunch of time with your
| project, I'm going to find someone else's.
|
| Even if, again, _even if_ , your non-standard way of
| abusing GitHub works for you, it's going to confuse,
| frustrate, and annoy everyone else you interact with.
| Which, if you don't hate your users, you should consider
| a big problem.
| Hackbraten wrote:
| > because you hate your users
|
| In which way do you think repeatedly stating that point
| is going to help?
|
| > because why would I look at closed issues... closed
| issues are generally resolved!
|
| I fail to see how this is related. Of course you may end
| up wasting your time with a new report - unless you
| include closed issues in your search.
|
| For example, a closed-resolved issue could mean there's a
| known workaround, which the user needs to apply. In that
| case, you have to look at that workaround to solve the
| issue for you personally. If you miss that closed issue
| and report it again, you're going to waste your time, no
| matter the semantics of "closed."
| ocdtrekkie wrote:
| > a closed-resolved issue could mean there's a known
| workaround, which the user needs to apply.
|
| I disagree. Because a workaround is generally, and should
| be treated as, temporary. Which means there should still
| be an open issue tracking the fact that your software
| _has an unresolved issue_.
| stblack wrote:
| Our stale bot doesn't lock issues, merely marks them as closed
| after a configurable notification time, and a configurable no-
| activity time.
|
| Which stale bot is the author referring to? This stale bot (THE
| stale bot?) https://github.com/probot/stale, doesn't even have an
| option to lock the issue.
| Ayesh wrote:
| I think a bit that closes (but not lock) issues that keetna
| certain criteria (maintainer marks is as "needs reporter
| feedback", and are support issues makes more sense. Big reports
| shouldn't be discouraged not stale-locked.
| ocdtrekkie wrote:
| I absolutely loathe stale bots. It essentially assumes a problem
| is irrelevant because nobody has fixed it yet.
|
| Sometimes I bother to ask the maintainer to put issues I report
| on hold. Mostly I just assume if you have a stale bot that you
| are going to wontfix all my issues and I should find a different
| project.
| no_wizard wrote:
| I feel this has a lot less value in a world where you enable
| GitHub discussions. While not a panacea, it does remove the
| clutter of 'issues as discussions' and allows you to really use
| the issue tracker for _just_ issues.
|
| This is what I would recommend every open source project do on
| GitHub:
|
| - Convert discussion issues to discussions
|
| - Label the existing issues as issue type (e.g. bug) if this
| makes sense for your project
|
| - Add an issue template that specifies if it is a feature request
| / discussion etc that it will be moved to discussions and they
| should proceed there, otherwise it can be filed as an issue
|
| - And importantly, close issues you don't intend to address, and
| a short explainer why (even if its just 'no longer relevant' or
| 'is not going to be considered, if requested open a new
| *discussion etc, make some boilerplate)
|
| That makes sense to me at least. I know discussions isn't perfect
| (far from it) however it cuts down the clutter on the issue
| tracker and makes it much easier I think to engage with the
| community (issues have this 'binding' status a lot of the times
| that discussions implicitly don't, so its much safer to spitball
| IMHO)
| chelmertz wrote:
| If the goal is to either reduce the number of open issues, or
| make it easy to find the most recently reported/recently active
| issues, it could be accomplished in other ways. What about:
|
| - not having "TOTAL issues" as a counter, but "TOTAL RECENTLY
| ACTIVE issues", for some value of "recently" - defaulting to only
| showing the RECENTLY ACTIVE issues when searching for them (or
| finding them through other views) - displaying a warning such as
| "this issues is dusty, consider it not being prioritized highly"
|
| As with all other bug reporting systems, having slices/views to
| work with seems to be preferred to closing issues. Someone
| supporting the product might really want to find the issues being
| "most reacted to" recently, the planning "product manager role"
| maybe only wants to see the high level
| "epics/initiatives/visions" in a certain order, etc.
|
| I think much of this comes down to all issues being on the same
| "level" in a Github issue tracker, i.e. "tagging is enough",
| which some projects solves with a huge taxonomy, and some don't.
| gmueckl wrote:
| Even when looking only at recent ticket activity, overall
| popularity of a project also plays into it. A young project
| that generates a lot of interest may attract a lot of reports
| and still work great. An old, unpopular project may be a hot
| mess but the ticket count is low because the user base isn't
| there to find issues in the first place.
| onionisafruit wrote:
| Number of issues shouldn't be a primary factor in evaluating
| a project. Maybe GitHub should stop featuring that so
| prominently in the UI.
| donatj wrote:
| We have had essentially this argument with our internal issue
| tracker a number of times. Project managers always seem to get
| some bug in their butt to close old issues.
|
| If they are not fixed, closing the ticket solves nothing.
|
| There is no virtue in having more untracked bugs.
| marcinzm wrote:
| I'm guessing someone is measuring the Project Manager's
| performance based on number of open issues. Or they think
| someone is doing so. Even if it's just a side comment from a VP
| noting how many open issues there are.
| Hackbraten wrote:
| In some projects, the maintainers use issues to represent their
| task queue. That's not necessarily intuitive for users but a
| perfectly legitimate thing to do.
|
| I think that if a project uses that model then there's nothing
| wrong with closing issues if you don't intend to ever work on
| them.
| mook wrote:
| I think in that case the maintainer needs a different view of
| the bug tracker; for example, in GitHub that would be their
| projects view, or if you don't like that, label the issues as
| stale (without closing) and using a search that excludes
| those results. I believe the important thing is to make the
| default search return the issues that the maintainers are not
| working on, so that known issues are still tracked (but
| possibly out of the maintainer's hair).
|
| The important thing is that new users would be able to find
| them, so that non-maintainers can still collaborate.
| NullPrefix wrote:
| >What gets measured, gets managed.
|
| Measuring open/closed issue tally is way easier than
| interpreting why and for what reason that particular issue is
| still relevant to the big picture.
| siraben wrote:
| Locking a stale issue seems a bit excessive to me. Nixpkgs, an
| extremely active repository (> 109K issues and PRs) has the stale
| bot configured to mark the issue or PR as stale[0] after 180
| days.
|
| [0] Example:
| https://github.com/NixOS/nixpkgs/issues/36217#issuecomment-6...
| Jugurtha wrote:
| Stale Bots are one thing, it's another thing when a huge company
| puts an intern in charge of issues and pull requests. You open an
| issue, and a pull request. The intern fails to see what the
| problem even is and closes the pull request _and_ the issue
| telling you they don 't see a problem. In other instances, pull
| requests would sit there for months for use cases that are no-
| brainers.
|
| We made the decision not to contribute to that project and not to
| maintain a fork. Instead, we developed plugins that are
| independent so we do not depend on pull requests being accepted,
| nor have to keep the fork in sync.
___________________________________________________________________
(page generated 2021-01-18 23:02 UTC)