Idea: Auto-close issues with no activity after X days

[eidolonnight]

We often refer visitors and contributors to our Github repo as a reflection of what we're working on. Having numerous open issues that have not been updated for months can be confusing to new contributors, and a hindrance to them finding meaningful work. The lack of activity also suggests that these tickets are either of a lower priority or blocked.

Auto-closing issues after a period of inactivity, something like 3-6 months, would help maintain a well-organized list of actionable issues without adding to the workload of team reps. Ticket authors would also receive a notification upon closure, allowing them to re-open the issue if they so desire.

Potential downsides are that this would require ticket authors and/or assignees to regularly check in and provide updates in order to keep the ticket open (a potential positive as well as negative) and new ticket submitters may be surprised by the automatic closure.

What are your thoughts? What time period would be acceptable? Are there other solutions?

[courtneyr-dev]

Historically, issues don't close.

• https://core.trac.wordpress.org/ticket/2833
• https://meta.trac.wordpress.org/ticket/30
• Add Block: Playlist gutenberg#805
• Integrate speaker feedback tool Learn#10

Instead, I'd encourage the team to pick which issues to focus on within a sprint. Say within a 3 month cycle, such as Q2.

[dd32]

One of my biggest gripes in the open-source world is running into a bug, searching the projects tracker for issues relating to it, and finding a bug from 5 years ago, never responded to by the project maintainers, and marked stale and closed a year later. Sometimes it'll have been re-opened, but then closed as stale again.

Admittedly, this repo isn't a bug tracker as such, but I don't think any automated "Lets just ignore this" should take place.
Instead, I would suggest what other teams do, and have a monthly/quarterly/etc sprint that reviews old tickets and closes them if they're no longer relevant, or sets the priority as appropriate.
Yes, it requires more human input, but it's better than an issue just being forgotten about because the tracking issue for it closed and no-one noticed because everyone was AFK on end-of-year holidays or something.

[eidolonnight]

I've always considered the lack of response and auto-closure as a sort of implied response: This ticket/bug is not important or otherwise irrelevant to the project at large. While it may be annoying, it tells me where that ticket stands and whether or not there's hope for it in the near future.

Periodic review and cleanup is also a valid approach, though as you mentioned, it will require more human input/time. My intent when I shared this was to clean up the issue queue while simultaneously decreasing the workload of contributors.

[bernard0omnisend]

I think it's important to appreciate the fact that this is not really bug-related, and many of the issues are related to campaigns/initiatives that were started and are either not yet completed (left "stale") or still in progress.

I think what we're trying to discover now is a way to simply optimize the process, and we're going to have to agree that we're all doing this to help improve the situation for everyone on the Marketing team. What @courtneyr-dev & @dd32 are recommending are really great ideas. Let's pick some topics, set them up as a target for any specific quarter, and tackle those. We won't be able to do everything at one time, but that means we'll be nibbling at the issue and hopefully making it an overall better experience for everyone.

[courtneyr-dev]

Also make use of GitHub Labels for things akin to "good first bugs" for any time contributions, and project boards. Let new contributors know where to go for these. Here's how we had organized these. Hauwa had served as a project manager to the team during her time as a team rep. https://make.wordpress.org/training/2022/05/03/may-2022-sprint/
Then at the end of sprints, we'd have a Retrospective meeting async. https://make.wordpress.org/training/2022/04/01/march-2022-sprint-retrospective/

[jennimckinnon]

Thank you for opening an issue to discuss this, and for the idea.

I absolutely, strongly disagree that Marketing GH issues should be closed automatically after a set amount of time. Here are my reasons why (many of which also echo what @Greennc, @sereedmedia, and @bernard0omnisend mentioned in the corresponding Slack thread:

1. Not every contributor is sponsored and can make specific time commitments, especially for larger marketing ideas.

2. If new contributors find the amount of tickets and lack of activity confusing, it's an onboarding issue, not one with tickets being open.

3. Some issues and discussions are related to campaigns or tasks that take years – not months – to complete, especially with global contributor input, and cross-team collaboration.
   Ex. Tide promotion #207
   Develop a widget for WordPress dashboard to offer Mobile app installation #201
   Create revised content for GitHub repo Contributor Day Handbook (cross-team collab) #192
   Moving GitHub issues that are used to explain process or structure of Marketing Team to Handbook #180
   Identify and update/create single page clarifying structure of WordPress plugin and theme ecosystem #179
   [Ongoing] WordPress Photo Directory Social Campaign - #WPPhotos #178
   Help develop topics and create marketing content for Make WordPress Developer Blog #171
   and many more. This alone should be enough to end this discussion.

4. Micromanaging or encouraging contributors may make sense for some teams where time-sensitive tasks are the norm, but that's not the case for the Marketing Team.

5. I don't think micromanaging or encouraging contributors to meet deadlines for every issue is realistic. Outside of the points already mentioned in this list, it may also be important to consider that some people don't work well being micromanaged, especially when they have other commitments or time/life constraints. It may also be worth noting that overall engagement in terms of marketing GH issues is currently low and has been for quite some time, despite some efforts to improve it.

6. When issues are opened, they are most often opened because there's a specific purpose or because there's already enough interest for an issue to be created. Automatically closing issues doesn't make sense as a result since it becomes an onboarding and engagement / team leadership issue, and not a problem with a lack of interest.

7. There are many issues in core that are years old that aren't automatically closed and sometimes later picked up and accepted; that's the point of open source.

8. Unless it's a completely inappropriate issue to keep open, it should remain open until it's complete. That's why issues are created in the first place in GH, it's because it can be worked on and completed. If it's an idea, it's a discussion that's open. There should be absolutely no reason for the need to automatically close issues as a result of this point alone.

9. Some long-standing issues are open because one or a few tasks still need to be completed but due to non-sponsored contributors having limited time they have not yet had the opportunity to complete the tasks to close the issues, but that doesn't mean it won't happen, even if it's a year from now. For example, the working group for the #WP20 From Blogs to Blocks campaign still needs to meet to wrap up loose ends, but we haven't been all available to do so and I would be very upset to see that issue closed when it's actually not completed, but will be at some point.

10. As @courtneyr-dev mentioned, historically, this isn't what we do project-wide. Unless someone can think of good reasons why the Marketing Team is the exception, I don't think it should be considered.

Instead, I propose:

1. Some contributors should set time every not-so-often to triage the issues, close any that are inappropriate to keep open like meeting prep issues from over a year ago, rather than close any issues automatically. Triaging issues could also include making sure issues are labeled correctly and that there aren't any relevant labels missing, and other similar tasks.

2. It's also clear that onboarding and engagement needs to be improved and part of that can begin to be resolved if a team leadership meeting is set up to work on goal-setting for this year, which hasn't been done yet.

As @sereedmedia mentioned on Slack, there weren't enough reps left with the capacity to onboard the new team reps sufficiently and so we haven't met yet for goal setting as we're all figuring it out our roles as best as we can and as much as we can on our own.

3. Perhaps it may also be helpful to create a survey / feedback form to ask contributors and potential contributors why they don't contribute to the Marketing Team (more often) as it may uncover pain points that we're not even aware of but do exist. It could also echo feedback that has already been received. It would help inform a strategy to increase engagement.

[eidolonnight]

For what it's worth, I do understand that there are other onboarding issues as well. I started the discussion for Documenting ongoing marketing projects so that we can help new contributors identify actionable projects and get started. I think that is important too, but even if we identify projects for new contributors, in my opinion, that still leaves us with a bit of a messy issue queue that has stale meeting and WordCamp issues.

The emerging consensus seems to be "don't do this automatically" and that sounds reasonable. It would certainly have benefits over the automatic approach that I suggested.

Some contributors should set time every not-so-often to triage the issues, close any that are inappropriate to keep open like meeting prep issues from over a year ago, rather than close any issues automatically. Triaging issues could also include making sure issues are labeled correctly and that there aren't any relevant labels missing, and other similar tasks.

My follow-up question would be "Who?" I can understand that many people probably wouldn't find an administrative clean-up task like ticket triage to be a fulfilling and meaningful way to spend their time, at least on the Marketing Team. So who would perform this periodic triage?

[jennimckinnon]

I think a role can be created for triaging issues and it could be something the reps or sponsored contributors complete. There may also be some people who may prefer clerical tasks because their day job is more mentally demanding, but they still want to contribute.

In terms of the Documenting ongoing marketing projects, I echo what @sereedmedia said in her comment. I think documenting this is super helpful, but it doesn't help with the points Sé raised in her comment, which I think are important to consider thoroughly.

If we address the points raised in that comment and the team reps meet openly to discuss goals that are aligned with W.org and the definition of "marketing," then more could be started to get organized and start helpful campaigns that garner more engagement and interest in our community.

[eidolonnight]

I think documenting this is super helpful, but it doesn't help with the points Sé raised in her comment

It was not intended to.