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

Configure MLflow repository with Probot-stale #1841

Merged
merged 4 commits into from Sep 13, 2019
Merged

Conversation

@ankitmathur-db
Copy link
Collaborator

ankitmathur-db commented Sep 12, 2019

What changes are proposed in this pull request?

Hey everyone!

As discussed, we want to be able to deal with older issues in a better way! Probot will go through issues and mark ones that have not been interacted with for a configured amount of time as stale. Some configurable number of days after an issue marked as stale has not been engaged with, Probot will close that issue due to a lack of activity.

In this PR, I propose marking an issue as stale if it has not been interacted with for 3 weeks. The issue would then be closed if it has not been engaged with for 2 months after it has been marked as stale. We can make this more aggressive as we develop more processes around dealing with issues! Notably, issues marked as enhancement are ignored by Probot, since it's likely that those would have longer lifespans.

As discussed, this would increase the visibility of issues and encourage more progress on them. This, combined with eventual JIRA integration, should dramatically raise the visibility of issues.

How is this patch tested?

Test in prod!

Release Notes

Is this a user-facing change?

  • No. You can skip the rest of this section.
  • Yes. Give a description of this change to be included in the release notes for MLflow users.

(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)

What component(s) does this PR affect?

  • UI
  • CLI
  • API
  • REST-API
  • Examples
  • Docs
  • Tracking
  • Projects
  • Artifacts
  • Models
  • Scoring
  • Serving
  • R
  • Java
  • Python

How should the PR be classified in the release notes? Choose one:

  • rn/breaking-change - The PR will be mentioned in the "Breaking Changes" section
  • rn/none - No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" section
  • rn/feature - A new user-facing feature worth mentioning in the release notes
  • rn/bug-fix - A user-facing bug fix worth mentioning in the release notes
  • rn/documentation - A user-facing documentation change worth mentioning in the release notes
@ankitmathur-db ankitmathur-db self-assigned this Sep 12, 2019
@ankitmathur-db ankitmathur-db requested review from smurching and dbczumar Sep 12, 2019
@ankitmathur-db

This comment has been minimized.

Copy link
Collaborator Author

ankitmathur-db commented Sep 12, 2019

Got some feedback from @mateiz that there may be issues that we want to fix, where users may not need to engage, and it might take us longer than the stalebot SLA to fix. In this case, we still want to have the issue left open. To this end, I've created a will-fix label and exempted it from staleness checks

Copy link
Collaborator

dbczumar left a comment

LGTM

@ankitmathur-db ankitmathur-db merged commit f19bd3e into master Sep 13, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@ankitmathur-db ankitmathur-db deleted the probot-config branch Sep 13, 2019
@smurching smurching added the rn/none label Sep 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.