Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update stale bot #6998

Merged
merged 2 commits into from
Nov 16, 2020
Merged

update stale bot #6998

merged 2 commits into from
Nov 16, 2020

Conversation

mtrezza
Copy link
Member

@mtrezza mtrezza commented Nov 8, 2020

This removes the stale bot that marks issues with prolonged inactivity as stale and closes them.

Due to the changes in GitHub labels, the stale bot is not needed anymore because all issues have to be attended to by the Parse team.

The issues that we see staying open for a long time without being addressed are either low priority bugs or feature / enhancement requests.

  • Bugs should not be closed due to staleness.
  • While there is no explicit team decision on how to handle stale features / enhancements, simply closing them makes issues with implemented features indistinguishable from issues with not-implemented features, reducing visibility for these open requests and decreasing the chance of someone picking it up. So before closing unimplemented feature / enhancement requests, we'd need to find an alternative way of ensuring visibility and activity around these stale requests.

@mtrezza mtrezza requested a review from TomWFox November 8, 2020 13:40
@mtrezza mtrezza mentioned this pull request Nov 10, 2020
@TomWFox
Copy link
Contributor

TomWFox commented Nov 10, 2020

On the second point can't we use 'up for grabs' to signify an unimplemented feature/enhancement and then continue to allow stale bot to close these?

@parse-community parse-community deleted a comment from codecov bot Nov 10, 2020
@mtrezza
Copy link
Member Author

mtrezza commented Nov 10, 2020

Interesting idea, so we'd close features and enhancements after inactivity and auto-apply the "up for grabs" label.

That would reduce the Parse Server issues to 1 or 2 pages immediately and we would mostly see only "real" issues that need to be addressed in the list. Sounds good.

My only concern would be discoverability of these FRs. Maybe we can add these feature / enhancement issues to a Backlog list on Github, so we keep them on a sort of Kanban rather than just in a pool of closed issues. I was going to suggest to use a Kanban for features and bugs anyway, so we can do proper release planning.

Edit: I don't think we can configure the built-in GitHub stale bot to only look at features and enhancements or apply the up for grabs label to only these issues. Have you seen any parameters to configure that?

@TomWFox Just to mention, we should make a timely change to the stale bot, because if it stays like that it will mark as stale / close all issues because the label names have changed.

@TomWFox
Copy link
Contributor

TomWFox commented Nov 10, 2020

I meant that a team member would apply the up for grabs label e.g. if the author isn't interested in implementing it.

Kanban sounds like a good idea, I agree we should try to keep visibility but we also don't want endless FRs building up because unless they are detailed / have meaningful discussion they serve little purpose IMO.

Update: I looked at the stale bot config and we could actually get it to apply up for grabs. All we have to do is change the label it applies on close from stale to up for grabs and then make issues with every label except feature and enhancement exempt.

@TomWFox
Copy link
Contributor

TomWFox commented Nov 10, 2020

Even better we can switch it to a whitelist (I think?)...

# Only issues or pull requests with all of these labels are check if stale. Defaults to `[]` (disabled)
onlyLabels: []

From the docs.

@mtrezza
Copy link
Member Author

mtrezza commented Nov 11, 2020

Oh there is in fact a whitelist option, neat.

Manually applying the up for grabs labels seems like the most time consuming task (which is continuously identifying issues that are inactive for n days) still lies with a human.

How about this:

  • author creates issue
  • repo member applies feature label and adds to backlog (adding to backlog could later be done by a bot)
  • issue becomes inactive for n days
  • bot applies up for grabs label, closes the issue and adds comment
  • issue gets active again
  • repo member re-opens the issue (and has to manually remove the up for grabs label?)

@TomWFox
Copy link
Contributor

TomWFox commented Nov 12, 2020

Sounds good, I think stale bot will remove the label when an issue is reopened.

@mtrezza mtrezza changed the title remove stale bot update stale bot Nov 13, 2020
@codecov
Copy link

codecov bot commented Nov 13, 2020

Codecov Report

Merging #6998 (8b387e1) into master (dbf04f3) will decrease coverage by 0.03%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #6998      +/-   ##
==========================================
- Coverage   93.85%   93.81%   -0.04%     
==========================================
  Files         169      169              
  Lines       12405    12407       +2     
==========================================
- Hits        11643    11640       -3     
- Misses        762      767       +5     
Impacted Files Coverage Δ
src/Adapters/Storage/Mongo/MongoStorageAdapter.js 92.92% <0.00%> (-0.67%) ⬇️
src/RestWrite.js 93.67% <0.00%> (-0.31%) ⬇️
src/RestQuery.js 95.51% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dbf04f3...8b387e1. Read the comment docs.

@mtrezza
Copy link
Member Author

mtrezza commented Nov 13, 2020

@tom I have changed the stale bot to

  • only consider "feature" and "enhancement" labels
  • mark them as "up-for-grabs" after 30 days with comment
  • close them without comment after 30 more days

Given our update frequency, 30 days seems reasonable. Issues are usually receiving an update within 7-14 days if they are active (that are 2 weekends for spare-time contributors). Giving an extra 2 weeks maintains visibility before closing it.

Adding a feature / enhancement as a "Backlog" card is something we can look into later on.

@TomWFox
Copy link
Contributor

TomWFox commented Nov 16, 2020

Sorry for the delay, I noticed that the comment about onlyLabels is that it will only consider issues with "all of these labels". I had a brief look on the repo and I'm not sure if this is true or not.

If that is the case it might be worth considering swapping to GitHub actions - they provide a stale bot type thing which is likely to be better maintained.

@mtrezza
Copy link
Member Author

mtrezza commented Nov 16, 2020

Yes, we can try it and see if it works. Either way we have to change the stale bot, otherwise it will be marking issues as stale. I manually removed the stale tag from 28 issues last time, don't wanna do that again :)

How about we merge this to try it out and take a look at Actions along the way.

@TomWFox TomWFox merged commit 8763993 into parse-community:master Nov 16, 2020
mtrezza added a commit to mtrezza/parse-server that referenced this pull request Dec 4, 2020
* commit 'ccb045b68c5b4d983a90fa125513fc476e4e2387':
  fix: upgrade @graphql-tools/links from 6.2.4 to 6.2.5 (parse-community#7007)
  fix: upgrade pg-promise from 10.7.0 to 10.7.1 (parse-community#7009)
  fix: upgrade jwks-rsa from 1.10.1 to 1.11.0 (parse-community#7008)
  fix: upgrade graphql from 15.3.0 to 15.4.0 (parse-community#7011)
  update stale bot (parse-community#6998)
  fix(beforeSave/afterSave): Return value instead of Parse.Op for nested fields (parse-community#7005)
  fix(beforeSave): Skip Sanitizing Database results (parse-community#7003)
  Fix includeAll for querying a Pointer and Pointer array (parse-community#7002)
  Init (parse-community#6999)
@mtrezza mtrezza deleted the remove-stale-bot branch August 20, 2021 23:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants