The motivation for the re-circulation is about keeping a clean backlog (both features and bugs) to ensure that they are still valid/ worthwhile should some random passer-by decide to spend time helping out (e.g. from one of the companies that we collaborate with or even a noolger looking for something to start on).  

That is to say, flipping the bug straight back to Available is an entirely reasonable triage response (assuming that it's still valid).  I get that the reviews don't come for free, but given the half-lives of many bugs in our tracking having an annual sanity check to ask "is this still useful?" still seems useful to me.

Would it make sense to perhaps adjust the text a bit, to better set expectations?

It's a fair point that a buildup of ancient features isn't really ideal. However, I also feel that features are a bit different from a triage perspective than a standard bug.

My experience is that many/most "type=feature" issues are written by a contributor to remind themselves of potential work at a later date, or to track work that is being immediately worked on. In many cases the feature isn't designed to be picked up by a third party as-is, or may interact with other code the contributor is an expert in. If a third-party were to pick up the bug to help out, they'd likely want to check with the initial filer.

Ideally, the filer / owner of the feature should be the one re-triaging it, as they can decide whether to obsolete it, make it available to others, or keep it for themselves. We might be able to achieve this a bit better with something like:

- If a feature is idle for X amount of time (1 yr?) set hotlist-recharge-cold and ping the feature with a message asking the owner if this is still something we want to work on. Don't un-assign or un-triage.
- If the owner doesn't respond by X days later (60?), either (a) close the feature as obsolete, or (b) un-assign / un-traige.

Not sure if adding something like this is a lot of work?

That's an interesting proposal, we'll discuss at the next sheriffbot meeting (next week).

A couple comments though.  The act of marking a bug as Available means that it's open for anyone to work on (i.e. versus an assigned task w/ out a milestone that would be specific to an individual).  If we are using it divergently, that will confuse folks since it's different than what we define publicly.

Even in the scenario where an individual files a feature bug, for themselves, we have sufficient turn over (from the team/ areas of ownership/ etc...) that the original filer may no longer be the correct owner/ commenter (even if the work is still valid).  As an adjacent example, this time last year we had ~10k issues that were owned by someone no longer on the project.

Given the fairly even distribution of Hotlist-Recharge-Cold issues (i.e. most components only see a handful in a 60 day period) [1] and that ~1/3 are getting closed [2], we likely will want to take a closer look at what's going on inside a subset of the components that have higher volumes before tweaking the process.  

[1] - https://bugs.chromium.org/p/chromium/issues/list?can=1&q=hotlist%3Drecharge-cold+type%3Dfeature+modified%3Etoday-60&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&sort=-modified&groupby=&mode=grid&y=Component&x=--&cells=counts&nobtn=Update

[2] - https://bugs.chromium.org/p/chromium/issues/list?can=1&q=hotlist%3Drecharge-cold+type%3Dfeature+-is%3Aopen+modified>today-60

laforge: did anything ever come of this discussion?

Sorry for the delay. For now we don't plan on treating Type=Feature as a special case for this rule for the reasons mentioned in c#1. I hadn't noticed it until just now, but it does seem like it's probably worth tweaking the wording a bit as laforge suggested. As part of this we can try to make it clearer that the right way forward may just be to ask the initial owner to take another look to try to address some of the concerns from c#2. cdavid, could you take a look?

To try to address the rest of c#2, in many cases the owner is the right person to do the re-triage, but (at least a the moment) it's hard for us to know if the owner is still actively working on the project. A big reason for having the rule is to shake out issues assigned to inactive owners. I think some potential legitimate issues could slip through the cracks if we just ping the owner and close without having the issue go through a proper triage cycle. The volume seems relatively low for now and I do like ensuring that these issues are revisited at least once per year.

We have another rule in place which will close them eventually if they are left Unconfirmed, albeit after another year. We should probably be more aggressive here, but we can consider this when we look for other ways to keep paring down the backlog.

We have modified the comment to address concerns from c#2.
Updated comment will as in  crbug.com/612652#c1