>>! In T113378#1666472, @Reedy wrote:
> We should define some sort of cut off for just abandoning commits (over some date, even more so if CR-1/CR-2 or V-1). They're just clutter. They still exist, and if someone wanted to work on them, they can be easily restored.
>
> Probably with a nice summary, "thanks for the commit, you can restore this at a later date if you plan on working on it" etc
>
> For example mw core has 29 commits untouched since 2013...
>
>
> You could argue that untouched patches over a year old are candidates for abandoning etc... Core has around 100 commits that are a year old
>>! In T113378#1672213, @EBernhardson wrote:
> This is a standard practice in some open source projects, and I think it would be a good idea for us as well. We can start off incredibly generous, only abandoning patches that havn't been touched in a year. But other projects (such as HHVM) will close open patch sets with three weeks of inactivity. It's not like the patches are lost, abandon just means its not going anywhere. Anyone who wants to can restore the patch set.
>>! In T113378#1672571, @hashar wrote:
> We had past discussion about it http://www.gossamer-threads.com/lists/wiki/wikitech/450845
See past discussions: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60150/ , http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/65931/ , http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/76459/ , http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/76640/
== Principles ==
Let's agree on the principles, as a required step to agree on the implementation.
# If a patch is ready for code review, it should be reviewed.
## When a patch has zero reviews, the burden is on the reviewers, no matter how old the patch.
### If the problem is that the repository has been unmaintained for a long time, then the patch submitter could be invited to maintain the repo.
#### If the search for new maintainers is futile, then the repo should be [[ https://www.mediawiki.org/wiki/Gerrit/Inactive_projects | marked as inactive ]] and the pending patches marked as abandoned.
## When the patch has +1 or equivalent, the burden is on the reviewers, no matter how old the patch. These patches should get priority in the queue.
## When the patch has -1 or equivalent, the burden is on the authors.
### If the patch doesn't have new activity, after a prudential period (1 month?) a bot should post a reminder.
#### If after the automatic reminder there is also inactivity, after a prudential period (2 months?), anybody is entitled to mark the patch as abandoned.
### When a patch had negative reviews in the comments not reflected with a -1, anybody is entitled to mark a -1 on behalf of these comments.
### When a patch has no reviews or +1 and is still waiting for review, it is not cool to force a -1 by throwing it to the Continuous Integration pipeline again, without specific negative feedback about the patch itself
#### If the patch looks good but needs rebase, it is cool to leave the good feedback in the comments and force a rebase, even if that results in a -1.
# If a patch is not ready for code review, it should be marked with [WIP] in the subject.
The concepts of +1 / -1 are specific to Gerrit, but if these principles make sense, we surely can adapt or evolve them for Differential.
**See Also:**
{T129068}
{T78639} (abandoning a rotting changeset = declining a rotting task?)