Marcus Kazmierczak 8:27 pm on January 14, 2021
Tags: core-editor ( 703 )

Stale Issues in Gutenberg Repository

In the Core Editor meeting on Jan 13th, a group of us discussed the idea of implementing a “StaleBot” that will automatically close issues and PRs based on a level of inactivity (no comments or commits) after a period of time. Before implementing, it was agreed that it would help to get more thoughts and opinions to make sure this idea is set up for success.

Please share your thoughts by Jan 29, 2021. If there are no major concerns, implementation will proceed.

Implementation Details

Using a stale bot is a common practice among repositories, the ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. project uses the Probot Stale bot to automate, with a 90 day policy. The bot allows customization of the time, messaging, and the ability to configure a specific label to skip auto closing. This gives great flexibility to make an implementation work for us.

The current recommendation is to set our policy to a 180-day of no activity, so if no comments or commits are on an issue or PR in 180 days, then the bot will post a comment to the issue alerting the user it will be closed in 7-days due to inactivity. The proposed message:

This is an auto-generated message to let you know that this issue has gone 180 days without any activity and meets the project’s definition of stale. This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a “bump” to keep it open, or add the “[Status] Not Stale” label. Thanks for keeping our repository healthy!

Important to keep in mind, closed tickets still exist, they maintain all the same info, are searchable, and can be reopened with one click. Further, if it turns out that this change has an unexpected negative impact, this can always be removed!

Leave Feedback

Feedback on the following by January 29, 2021 would be the most helpful:

What concerns (if any) do you have about implementing this?
Does 180 days of inactivity seem like the proper time threshold?
Does giving 7 days to respond feel like enough time?
Is the message clear yet friendly enough? Would you make any changes?

#core-editor

Daniel Llewellyn 8:38 pm on January 14, 2021

My personal opinion is that bots automatically closing issues is obnoxious *expletive*. If a project definitely does not care about fixing problems or implementing suggestions then automatically closing an issue that a user cares enough about to have filed a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. under the, obviously misguided, impression that they would be listened to is acceptable. On the other hand if we care about users and that they trust that we will fix their problem then automatically closing their issue gives them the signal that we don’t.

If you don’t want to fix a problem then it is better for a human to explain why the problem won’t be fixed and personally close the issue. Automating this on the assumption that because nobody has commented in a while means it isn’t important is bad!

Almost every issue that I have had closed automatically is about a problem that I have had, and still had at the time of closure, but there wasn’t anything I could add to the issue that I hadn’t already said. I believed that the ball was in the maintainers’ court and thus the automatic closure was triggered because the maintainers’ refused to respond before their obnoxious bot got to it.
- Neil Murray 9:20 pm on January 14, 2021
  
  I have no concerns with this being implemented. After 180 days of inactivity a ticketticket Created for both bug reports and feature development on the bug tracker. is not achieving much by remaining open without action.
  
  If the OP doesn’t want it closed, they just need to be interested enough to add a comment when they receive the notice, by saying something like this is still a problem. Also if they ever have more to contribute, after ticket is closed, they can easily re-open it.
  
  The 7 days to respond seems OK but could be raised to 14 days if others think it’s too tight. The message is clear & friendly.
- Marcus Kazmierczak 9:25 pm on January 14, 2021
  
  Thanks for the feedback, and I understand where you are coming from, though maybe not your tone.
  
  The bot is configurable anyway we wish, so it would be easy enough to have it skip issues labeled `[Type] Bug` or whatever makes sense.
  
  Right now the repository has 2,700 open issues which makes it quite hard to manage. The overall goal of the proposal is to improve feedback and responses to issues by ensuring what’s there is relevant.
  
  There are also over 500 open PRs, which my guess that any older than 6 months might take more work rebasing than the work there.
  
  Also for either issues or PRs, to reset the 6-month clock only requires a single “bump” comment to indict “yes, this is still important to me.”
  - Daniel Llewellyn 9:29 pm on January 14, 2021
    
    But the number of open issues will only be artificially reduced by closing automatically. Users that have reported a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. and had a warning about the bugs impending closure will either forget to bump it or feel alienated by the warning and the lack of care the project is showing by ignoring their issue until it is due for sweeping under the carpet. It will then still be a problem but has zero chance of being fixed until another user, or the original user, opens a new issue or reopens the dead issue – either way the number of bugs was only reduced for the duration of time until someone hits the issue again.
    
    Closing an issue as #wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion. should ALWAYS be a human decision.
    - Ian Dunn 4:47 pm on January 15, 2021
      
      the number of open issues will only be artificially reduced
      
      In some cases it’s artificially reduced, but not in all.
      
      I’ve personally had ~4 of my issues unknowingly fixed by another issue/PR. Later on, someone tried to reproduce mine, and they weren’t able to.
      Users […] will either forget to bump it
      
      Can you elaborate on that? I’m not sure how someone would forget; they have the email notification and can just reply “bump” when they get it.
      […] or feel alienated by the warning
      
      I definitely agree that the phrasing of the message is very important. It should genuinely thank the reporter, and help them understand the problem that’s being solved by closing stale issues, and encourage them to bump if they feel it’s appropriate.
Joy 9:02 pm on January 14, 2021

What Daniel said times 1000!
I’ve had issues closed by humans for being stale, also, and it isn’t any better.
I’ve had issues closed because someone created a new issue on the same thing. This loses all the history and the watchers.

I’ve also had an issue closed at Launchpad for being stale (and their system used only two weeks as a time frame). That served no purpose at all. It only makes people go away, frustrated.
- Marcus Kazmierczak 9:28 pm on January 14, 2021
  
  > created a new issue on the same thing
  
  This is exactly one of the drivers behind the thinking in this change, with so many currently open tickets, it’s much harder to find existing bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reports to add to, so people file their a new one that as you say creates more problems.
Luke Carbis 9:27 pm on January 14, 2021

As a developer, I find the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repo difficult to approach due to the sheer volume of reported issues. Although I understand that having your issue auto-marked as “stale” can feel terrible, I think that it’s worth the tradeoff to clean up the repo – especially since it’s so easy to keep an issue open or reopen it.
- Daniel Llewellyn 9:33 pm on January 14, 2021
  
  closing an issue automatically gives the user the impression that the bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. isn’t important and therefore will not be fixed. The warning is then seen as a notice to “go away”. If the number of open issues is a problem then a/some humans should triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. them and close those that will not be fixed with a human-written message explaining WHY the issue isn’t important enough to be fixed.
Robert Anderson 11:14 pm on January 14, 2021

Copying over what I wrote in #core-editor:

I really like the idea of sharing the load of testing and triaging issues with the issue’s author
Clearly it doesn’t work well if we just have a few team members doing all of the testing and triaging. Hence our large backlog 🙂
This is an open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project which means that we can take advantage of “many hands make short work”
That’s why I wanted to update the issue templates to encourage reporters to do a little upfront investigation
So. My point: I like the idea of a bot that closes issues, but I think let’s treat it as an opportunity to engage with the author (“hey! help us out! does this issue still happen?“) rather than dismiss them (“hey! this issue is stale so I’m closing it!“)
Peter Wilson 5:21 am on January 15, 2021

What concerns (if any) do you have about implementing this?

I’m not a big fan of bots closing tickets due to inactivity alone. On a large project driven by volunteers, both personal and corporate, the boring but important tickets can age while the new and shiny is worked on.

I fear auto closing would result in a number of bugs falling through the cracks because the reporter hasn’t anything to add after their initial report.

My preference would be for a bot to alert humans in a slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel when a ticketticket Created for both bug reports and feature development on the bug tracker. is declared stale and become progressively more insistent until a human responds.

Does 180 days of inactivity seem like the proper time threshold?

For being declared stale, yes.

Last month (ie, tickets from June 2020) would see 107 issues and two PRs closed. These numbers might be a little low due to the northern summer holidays.

Does giving 7 days to respond feel like enough time?

If this goes ahead, I’d prefer 21. This allows time poor volunteers to respond. A long window probably needs a reminder 7 days out though.

Is the message clear yet friendly enough? Would you make any changes?

As above, I’d prefer something to come from a human.

If a bot is to reply, then I think it needs a little work.

Hi

This ticket has gone 180 days without any activity and therefore meets the project’s requirement for a check-in to ensure it is not obsolete. If you are still experiencing this issue, then please reply with confirmation and any updated reproduction steps.

Thanks,
GuteBot
- Milana Cap 9:29 am on January 15, 2021
  
  I like this plan.
  
  Even though I have nothing against ticketticket Created for both bug reports and feature development on the bug tracker. being closed by the bot without warning (maybe a note when opening an issue/PR), I see in other comments that this idea is perceived as hostile.
  
  Using bot to gently nudge ticket author in time seems like a good compromise between being friendly and thoughtful to contributors while keeping maintainers sane.
- Mark Barnes 1:59 pm on January 15, 2021
  
  I like this plan too. It seems much friendlier asking for a check-in than “threatening” to close the ticketticket Created for both bug reports and feature development on the bug tracker.. The result can be the same, but I much prefer this approach (carrot, not stick).
- Ian Dunn 5:11 pm on January 15, 2021
  
  Yeah, I really like the idea of a bot sending an initial message first, just asking for an update. If they don’t reply to that in 14-21 days, then we could close it. That’d take some of the sting out of it.
  
  I think that’s a good overall lesson for the industry. When we setup bots to interact with humans, we tend to make them rude. It can help to ask ourselves, “If I were going to do this manually, with someone I like and work with closely, how would I approach it? How would I phrase it?”
- annezazu 6:54 pm on January 15, 2021
  
  I like the rephrase to specifically call out “gutebot” or whatever it ends up being named 😀 I would like to leave in some sort of “thank you” here though whether it’s “Thanks for keeping our repository healthy!” or something else.
- dgebel 1:14 am on January 20, 2021
  
  Definitely much better tone Peter!
  I would add MrWWeb’s explanation of why auto-closure is helpful and I would feel I was a reasonable request & action.
  I’ve definitely had issues that I’d forgotten about, and weren’t a problem any more.
Greg Ziółkowski 6:41 am on January 15, 2021

As the first step, we could use the bot to label the issue or PR as stale when it meets the requirements proposed. It could also add the message that would explain why it’s marked as such with the prompt to take some actions to increase the chances it doesn’t get closed. It looks like auto-closing is the most controversial part here, so we could start doing weekly triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. where people go through those issues and close them only when they aren’t actionable anymore. Otherwise, they would remove the label and add a comment which would restart the staleness timer.
- annezazu 6:53 pm on January 15, 2021
  
  I really dig this approach! I think with a few parts of automation working together to properly snag human attention will go a long way. For the reporter, I agree with others that the message definitely needs to be extremely friendly and welcoming.
- justlevine 12:12 pm on January 18, 2021
  
  Came here to write this, happy you beat me too it.
  Although I agree whole heartedly with Daniel in the first comment, so I wouldn’t call this a ‘first step’, if the implication is autoclosing down the line.
  
  Labeling and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. to manually close has my vote!
Ian Dunn 4:37 pm on January 15, 2021

[closed issues] can be reopened with one click

Is that accurate? I think that’s only true for people with elevated privileges, or if the author of the issue was the one who closed it.
- mrwweb 10:06 pm on January 15, 2021
  
  I would just add that while it is certainly true that closed tickets can be reopened, it is much harder to find closed tickets (including to see if you’re reporting a known issue) and “can be reopened with one click” probably overstates the likelihood of this happening frequently.
mrwweb 10:23 pm on January 15, 2021

Does 180 days of inactivity seem like the proper time threshold?

For new tickets, yes. For existing tickets, I worry about the initial wave of closing tickets. As someone with a number of old, mostly valid tickets, I already fear the influx of emails. Could the bot initially use a longer window (365 days?) and then progressively shorten over a few months to 180 days?

Does giving 7 days to respond feel like enough time?

No. If the goal is to help distribute the load of testing and reconfirming issues as valid, it should be at least 14 days. I like the 21 I’m seeing elsewhere in the comments. Many bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. filers are busy people with day jobs, kids, etc. that need more time. (The argument against a longer window is that reduced urgency mean people forget about this and it closes. I could be convinced.)

I also wonder if allowing for additional time will reduce the number of people who just reflexively comment “bump” without testing. While “bump” works to keep the ticketticket Created for both bug reports and feature development on the bug tracker. open, it neither provides new information nor confirms the issue is still valid. I think it’s worth mentioning, but only as a action of last resort.

Is the message clear yet friendly enough? Would you make any changes?

How about explaining the purpose of marking issues as stale? It’s implied in the last sentence but could be called out.

Rough idea of changes:

This is an auto-generated message.

This issue has not had any activity in the last 180 days. It will be auto-closed and labeled “Stale” if there is no new activity in the next 14 days. Closing old, inactive tickets helps focus a project on active bugs and improvements. Older tickets are more likely to be fixed or no longer relevant.

If the issue is still relevant and active, please leave a comment to keep the issue open. Even commenting “bump” will keep it open. Thanks for keeping our repository healthy!

Note: Normal users can’t label issues, so I’m removing that from the message.
Francesca Marano 8:32 am on January 19, 2021

Thank you @mkaz for the proposal and everyone for chiming in.

What concerns (if any) do you have about implementing this?
My only concern is alienating contributors. It is true that also having your ticketticket Created for both bug reports and feature development on the bug tracker. open for years with no action in it feels very demotivating, but having a machine close it because of inactivity can be seen as a lack of empathy from the project towards its contributors.
That said, I second @lukecarbis‘s feeling of overwhelm when faced with the number of issues in the GB repo.
I would definitely encourage us to test an engagement bot rather than an auto-closing bot, as proposed by @gziolo

Does 180 days of inactivity seem like the proper time threshold?
I would make it at least 365 as a first step.

Does giving 7 days to respond feel like enough time?
Nope. Even as a full time sponsored contributor 7 days is like tomorrow 🙂 I would make it 30 as a first step.

Is the message clear yet friendly enough? Would you make any changes?
It doesn’t read very friendly to my Italian ears. It will need to change if we go the “engagement” route instead of the “autoclosing”, and I would definitely like to see some of the WP quirks infused into it. You know, howdy, giving it a name, etc…
skorasaurus 8:00 pm on January 21, 2021
There are so many issues and it can certainly feel overwhelming and this is unfortunate for everyone involved. I applaud the effort and there are good intentions but I am disappointed by the approach so far.

What concerns (if any) do you have about implementing this?

I’ve done a fair amount of triaging (maybe >200 issues, includes commenting on issues but also ensuring that there’s appropriate labels on them) in the past 3-6 months; and anecdotally, a majority of issues that hadn’t been updated in >6 months were to me, at least still applicable. There are certainly some issues that I’ve found that are not longer applicable and I’ve close(d) them.

Perhaps, I’m naive, but as someone who has triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. privileges, I thought it was not recommended to post ‘bump’ in an issue that is still active and applicable if the issue was one that that is more architecture-oriented, feedback-based, or feature/user requests like: https://github.com/WordPress/gutenberg/issues/12707 https://github.com/WordPress/gutenberg/issues/14256 https://github.com/WordPress/gutenberg/issues/12101 and https://github.com/WordPress/gutenberg/issues/9117

If it is recommended to ‘bump’ issues that aren’t ones that necessary bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-based and are issues like I linked to above, please include that in the triage documentation )

That there are so many issues is inevitable and expected because of two primary reasons:
* this is an extremely ambitious project and what it is trying to solve is very large in scope – a brand new editor!
- Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. have decided to prioritize adding additional functionality (full site editing, converting widgets to blocks) in the past 6-12 months instead of addressing existing issues. Some open issues will be answered/resolved by new initiatives like G2 components and global styles and there is also certainly work being done on long, outstanding issues (I want to specifically recognize Glen Davies here for refactoring the gallery blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. https://github.com/WordPress/gutenberg/pull/25940 !)
It is worth stating that the number of open issues has remained relatively consistent (between 2.5 and 3k) for the past year or so.

Considering there is also an unprecedented global pandemic occurring, it’s reasonable that previous expectations of FOSS contributions aren’t applicable and people may be less able to participate.

As for open PRs:

I only review PRs on a limited basis nor do I have the capabilities to approve changes (I don’t want them) so my experience is limited but it worth sharing that:

Of the 546 open pull requests, More than 75% of them (420) are ‘awaiting review’ which means that they need to be reviewed by core contributors and are awaiting action by the core contributors and not the PR’s author.
Compared to 58 issues (out of 546) at are labelled as ‘changes requested’ which means that it has been reviewed by core contributors and needs further follow-up by the author.

Closing outstanding PR’s that haven’t been updated with ‘awaiting review’ tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) solely because a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. member hadn’t reviewed it, creates disincentive for potential contributors.

I do like the proposal of prompting the original author to make a new comment
that the issue is still relevant and that they were able to reproduce on the most recent version of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.

Does giving 7 days to respond feel like enough time?
I would agree 30 days would be more reasonable.

Is the message clear yet friendly enough? Would you make any changes?
you can simply comment with a “bump” to keep it open, or add the “[Status] Not Stale” label.
I would rephrase that text and remove the bump reference; those who aren’t very familiar with some internet subcultures wouldn’t know what a ‘bump’ means, how to ‘bump’, as well as those who are not fluent in English. Also most users do not have permissions to add a label and would become confused when they are not able to add a label.
Matt Mullenweg 5:30 pm on January 22, 2021

I am strongly opposed to stale bots. I also agree our open issues are too high.

I’d like to better understand what would be required to tackle this in a more nuanced, human way, and and if we have a good estimate for how many people working how long, try to use that to rally the community around tackling this problem.

If it works, it would be a best practice we could apply to WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., too.
- Marcus Kazmierczak 5:49 pm on January 22, 2021
  
  Let’s assume we don’t do any auto-closing, since that seems to be the most controversial aspect, and I agree not a warm “we care about you and your problems” message that we want to convey.
  
  I’m reaching out to some people doing triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. to see if we can measure the level of effort, but to note the automation idea also came from them to help their efforts.
  
  Do you see a bot as still the wrong approach to help re-engage reporters in their issue? A message along the lines of “Hi, wanted to check back that this issue reported over 6 months ago is still valid in the latest version? If so, thanks for reporting and confirming, if not can you close the issue. Thanks for helping keep our repository up to date!”
Paal Joachim Romdahl 6:28 pm on January 22, 2021

I have been doing some marathon triaging Monday and today (Friday) around 4 hours each day. I pinged the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ leads way too much on Monday. But it gave results. On Monday we had about 2,770 ish open issues. Today that has gone down to 2,713 open issues.

I many times I just add a message where I pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” the original author and some of the other commenters asking for an update or asking if the issue is still valid.
If there is a broken Gutenberg feature from 2018/2019 I will test using Twenty Twenty One, newest Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and WP 5.6 and see if the issue is still valid.

It was actually this post by Marcus that got me into a high gear in working on resolving older issues. Some of these issues are features that are planned to be worked on sometime down the line.

I do wonder if we should have a stalebot that becomes active when the issue is one year old. Ping the author of the issue. Then after two weeks with no reply have it ping someone to take a closer look at the issue.
- Mukesh Panchal 4:28 am on January 25, 2021
  
  Agree with @paaljoachim thought.
Sergey Biryukov 7:24 pm on January 29, 2021

What concerns (if any) do you have about implementing this?

I noticed in the discussion in #core-editor that a question was raised of applying a similar policy to CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.:

I know Core Trac has some very old tickets and doesn’t have this policy, though I’m not sure if that is due to a lack of automation tools or actual repository policy.

So I’d like to provide my perspective as someone who mostly works on Core Trac 🙂 In short, I don’t think any automated or semi-automated solution for closing stale tickets like that would work for core.

Two years ago, there was a precedent of closing ~2300 tickets that had not been modified in at least 2 years: “Follow Up on Recent Trac Bulk Edit”. This was not received well by the community (maybe in part because it was done without any prior discussion), and was reverted a few weeks later: “Reverting the Bulk Ticket Closing”.

It’s true that some portion of tickets submitted a long time ago might have been fixed elsewhere in the meantime, should have been support requests in the first place, or might no longer be relevant, e.g. enhancements for the Classic Editor.

However, the majority of tickets are generally still valid even after a few years. I think it’s not fair to the contributors who may have spent a significant amount of time creating these tickets and patches to close them out just because we didn’t have enough resources for reviewing them; that would be quite discouraging and doesn’t really solve anything. JJJ’s comment goes into more detail on this.

tl;dr I think every open ticketticket Created for both bug reports and feature development on the bug tracker. should be properly triaged to receive the attention it deserves. It’s fine to close an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. as “maybelater” if there’s not enough interest at this time, or to close a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. report as an acceptable edge case if there’s clearly no point in fixing it. It should, however, be a conscious decision by someone familiar with the component, and not just because the ticket had not been modified for a while.

This could be reconsidered again in the future, but would need to be thoroughly discussed from all points and clearly communicated. I think finding ways to increase the number of component maintainers and triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. sessions would be a better option to bring the number of open tickets to a more manageable state.
Anthony Hortin 3:11 am on February 3, 2021

Agree with what Pete, and others are saying here. You shouldn’t just auto-close someones issue. That’s an arrogant approach and extremely frustrating for the person who’s taken the time to raise the initial issue. I have dozens of bugs and issues still open dating back to early 2018 that nobody on the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ team has bothered to address, and that are still relevant. If nobody is going to fix the bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. then the very least that can be done is for someone on the Gutenberg team to provide a valid reason as to why it isn’t going to be fixed or addressed, before it’s (manually) closed.
Marcus Kazmierczak 11:26 pm on February 9, 2021

Thank you everyone for your feedback. We’ve taken it into account and have created the proposed issue here for implementation.

See the proposal for details, but the two big takeaways is not to close any issues as it seems dismissive , and use the bot as a reminder to help re-engage users.

Comments are closed.

Welcome!

Communication

Stale Issues in Gutenberg Repository

Implementation Details

Leave Feedback

Welcome!

Communication

Implementation Details

Leave Feedback

Share this: