[Policy, no patch] Adjust major and critical task thresholds during code thaw

Updated issue summary.

Thanks for opening this. Bumping to major...

Updated issue summary.

During the time just after I became a core committer, I had to check the issue thresholds regularly due to commit procedures (thankfully, I no longer have to do that). During those several weeks, I never saw any of the 4 thresholded issue counts get below its threshold by more than 1 or 2 issues. I have also been aware that one of the main "solutions" when any of the 4 counts got above thresholds was to re-classify issues until the counts were sufficiently reduced -- making me really skeptical of the whole threshold idea, I have to say. And it appears this pattern I observed 6 months ago has been ongoing.

Given that, my guess (yes, it's only an educated guess) is that if we raise the threshold for tasks to different numbers, the number of critical/major tasks will quickly jump to those numbers and then hover there (plus or minus a few)... and we'll have the same problem that we have now, at those new numbers.

So... I think there are 3 possible courses of action:

a) Do nothing: Continue as we are now, with the accompanying badness as outlined in the issue summary.

b) This issue's suggestion: Raise the task thresholds to different numbers -- which I surmise (but of course cannot prove until it's done) will shortly lead to having the same badness at those different threshold numbers.

c) My suggestion:
- Get rid of the thresholds for "major" D8 tasks entirely until feature freeze (keep the "critical" task threshold where it is).
- Set the category of issues that were artificially classified as features/support back to tasks.
- Correctly prioritize the tasks that were demoted to "normal" to a more realistic priority. But only prioritize a task as "critical" if it should really be blocking other work -- we can edit the "Priority" explanation page to make that clear.
- Make sure that all the tasks that do really need to be done between feature freeze and release are prioritized as "major".
- After feature freeze, set an appropriate release threshold for the major tasks that will ensure that they really get done before release.

I believe that adopting this would let work proceed, while still giving us an accurate picture of the remaining work that needs to be done after feature freeze to get to release. Thoughts?

Can we just get rid of the issue queue thresholds altogether? I understand the original idea ("Never be too far away from a release"), but that's not really how it's working. We still have a lot of important crap to do and the issue queue thresholds are just encouraging us to make them not as important (best case), artificially marking issues as a support request so that they don't count toward thresholds, or just blocking work from getting done because we're over some artificial limit (worst case).

Re. #6, I disagree strongly that the limit is artificial. It's what makes majors and criticals visible, because we legitimately care about how many there are. It results in properly triaging our majors and criticals, and it results in people working in parts of the queue they otherwise wouldn't when they want a feature in. Since I've been working on VDC, the temptation is strong to just ignore the rest of the core queue, but every time something goes over thresholds, it's motivation to go back and help kill a major once in awhile if I know Views can't be merged in.

#5 is not applicable because there is no threshold for features, only tasks and bugs.

The point of the policy is to constrain our technical debt.

@jhodgdon's (c) is worth considering, especially if we restore the threshold Dec. 2, though I still think we should bump the critical task threshold to 25. In some ways, though, right now is the most important time to have a threshold, because right now is when the temptation is strongest to shove stuff in core and damn the technical debt.

The problem of managing technical debt has two sides:

a) Understanding what the technical debt is -- which requires that issues never get artificially miscategorized (priority/category).

b) Keeping it to a reasonable level (and what "reasonable" is should really depend on where we are in the development cycle).

We just never ever ever ever ever should be mis-categorizing issues for the convenience of fooling ourselves into thinking the level of technical debt is reasonable. That behavior is what leads to reasonable people into thinking that the issue thresholds are artificial and a joke and silly and meaningless.

if we restore the threshold Dec. 2

Do we even still have threshholds after Dec. 1? At that point, no new large features can go in anyway. I guess we can apply the threshholds to the "integration" / "clean up" features that will still be allowed up until code freeze, but what's the value of slowing down integration and cleanup, since those are things that pay down technical debt rather than increase it.

The way I interpret this issue, our current threshholds have worked and are working in slowing down the rate at which we add features to a level that keeps our technical debt at a level we can sufficiently pay down during the feature freeze to code freeze window. The consequence of this slowdown is that we will get fewer features completed by Dec. 1 than if we didn't have those threshholds, again, by design. So, the question is, do we feel that it is best to continue that strategy, or is it more strategically important to the Drupal project at this point to get more features finished? If the latter is true (though I don't know that it is), we could just stop the threshholds entirely, and accept whatever increase to tech debt will occur in the next 7 weeks. Or, if we want to keep throttling some features, but stop throttling others, we can identify the 2nd list, and stop applying threshholds to them only.

As far as the problem of issues being miscategorized or misprioritized intentionally in order to game the threshhold system, there's two aspects to it:
- Until someone classifies the issue correctly, there's nothing we can do, and this will be true no matter what the threshholds are set at.
- Once someone classifies the issue correctly, it becomes harder for someone to reclassify it in a way that games the system. Anyone can reclassify, of course, but usually people provide a reason when doing so, and being too obvious in "classifying this release blocker as a normal in order to game the threshholds" is something we can apply social pressure to stop doing.

@earnie, the major and critical tasks are respectively the things we should do and need to do before we can release Drupal 8, by design. :) So we can't move them to the next branch yet, I don't think.

Another option would be to create the next dev branch, e.g. 9.x-dev and assign all issues not related to the feature frozen branch

But we're not in feature freeze yet. We're in feature thaw, so every feature is in principle still a candidate for D8. Some are far less likely if no one thinks they're sufficiently important, but Drupal's a do-ocracy, so anything that seems not likely now can become very likely tomorrow if someone decides it's their itch to scratch. Once we're at the feature freeze date, then I think it will make sense to add a "9.x-dev" version to the issue queue and start moving issues to it. Even then though, there won't be a 9.x git branch, since Dries will not have selected his D9 comaintainers by then, and will not want to be spending his own time on D9 reviews. Active 9.x development won't start for quite a few more months, though people are of course welcome to start on whatever crazy thing they want to start on in their own sandboxes.

I think increasing the threshold to 125 might not solve the problem permanently, as @jhodgdon suggests. No way to know for sure, and I'm not sure how to induce that cultural shift in the longterm. But it might bring some of the hiding tasks out of the woodwork to give us a more accurate picture for the next 7 weeks while still making it clear that the technical debt matters.

What thresholds can be used for during feature freeze is as a blocker for cleanups that can be deferred to code freeze. @webchick often states that we shouldn't worry about that because we can just revert stuff, but in practice that really doesn't happen. I've repeatedly both been the author of "polish patches" that resulted in hours-long rerolls of major changes, and been the one rerolling, and in both cases I've wished I could go back in time and un-file the cleanup issue.

@catch has also suggested accepting limited additional small feature or API improvements during freeze if thresholds are low enough, as an incentive to keep people helping out, but that's probably a separate discussion.

The primary advantage of the thresholds, IMO, has been to force people to write change notices. :-) Beyond that, I don't know how effective they've really been. I'm not a generalist, though, so I am perhaps not the right target audience.

I think they've been extremely effective, actually. People often come out of their little boxes to help fix issues when we're over thresholds.

Then would raising the thresholds just discourage them from coming out of their boxes until we get back into the "same thing only higher" situation jhodgdon describes?

Updated issue summary.

@Crell, there's sort of an offset. The numbers crest over the thresholds, then people look for things they can help with, then over the next several weeks they work on the issues they find, and then the counts drop well under thresholds as the issues they've helped with are resolved. I've seen that happen repeatedly.

We're right now in one of those phases--with people with a particular feature in mind helping out elsewhere--so I think folks will continue to work on what they are, but also hopefully stop lying about the technical debt they know about because of social pressures.

FWIW, full disclosure, issues over thresholds are also a signal to me to go through and identify the actionable steps in an issue so that novices can help with them. So I like them for that reason too.

And with that I'm done discussing this for now. :)

Then would raising the thresholds just discourage them from coming out of their boxes until we get back into the "same thing only higher" situation jhodgdon describes?

Yes. Whether or not that's a good thing is the question. If the box those other people are in is playing World of Warcraft, then it means we lose out on some extra Drupal love. If the box those other people are in is working on a feature we really want to get in by Dec. 1, then sounds like some people would prefer those people to stay in that box.

The thresholds were introduced to prevent exactly this from happening.

@sun: Can I just say... Coming in on comment #19 and abruptly closing an issue as "won't fix" when others are still participating in having a discussion comes across, to me at least, as exceptionally rude. Communication via issue comments loses a lot compared to face-to-face communication, so it would be nice if everyone could be extra considerate and think about how things like this could be perceived.

We are all considered equal in this project, hopefully -- none of us has final say on decisions, and hopefully we all value each others' opinions. It would be a lot better received (by me, at least) if you added a well-thought-out, considered opinion as a comment rather than closing the issue with a "won't fix". Doing it this way makes me think that you believe that yours is the only opinion that matters. Be direct, yes. Disagree, yes. But be respectful about it. Just a thought...

See also: http://drupal.org/dcoc

@jhodgdon: Thanks for reminding me of that.

And thanks to the carefully crafted OP, some more reasoning is required:

Drupal 8 is in a poor, an extremely poor state. It might work on the surface, but in reality (in terms of Drupal developer/site builder/themer reality) it does not. The critical/major priorities are frequently gamed with, they do not represent the actual state of the system. It would be impossible to release D8 now. Reality is, it would be impossible to release D8 in 3 months from now.

The core issue thresholds have been introduced to prevent that situation. We have them to avoid a sheer never-ending backlog of issues that are blocking a release. Over time, a huge number of issues got demoted from critical/major priority in order to get below the thresholds and make room for things that are actively being worked on. At the same time, various new issues for newly introduced functionality have been created, intentionally using a priority that does not block other things from moving forward, but which are critically important in reality.

Reality is, we are way beyond our thresholds. Way beyond the numbers you are suggesting.

So. We introduced the thresholds. We played them. We demoted "not super critical" issues, and we filed new critical issues as non-critical to begin with. If you'd ask for it, you could have twice or thrice the critical/major queue numbers by tomorrow.

But that is not the point.

Playing with issue priorities is acceptable as long as the community can get behind that and wants it. The point and meaning of thresholds is much more implied — the thresholds do not fail on their original goal, because they are still a successful measure on the state of things. The fact that we are continuously near or exceeding the limit only testifies that we already have a never-ending pile of unresolved crap that only gets larger. And we are in this state even after multiple sprints of playing/demoting issue priorities. If you look at the actual current critical/major queue, you will realize that the majority of issues is caused by new functionality. We played well. :)

The point of the issue thresholds we put in place is much more psychological from my perspective in the meantime. I can only applaud @webchick, @catch, and @Dries for abiding by them, even in situations in which significant new killer functionality has been proposed.

To my knowledge, all three of them made exceptions to the imposed rules at least once already. And that is acceptable, because they are effectively in charge of the release and responsible for ensuring overall sanity. I also applaud everyone who successfully managed to "overrule" them by providing sufficient reasoning for why an issue must be critical or major. But in the end, that's issue priority futzing, needless noise, and a waste of contributor time.

Contrary to that, what matters for us core code monkeys is to have a good grasp of the current state of art, which critically includes to being told that we're out of bounds, that we've cumulated enough code debt ("again") to prevent a stable release from happening anytime soon. This is the case already, regardless of how you put it. Adding 25+ more issues to the allowed thresholds does not change the reality. It only obscures reality even further and moves the "sudden" WTF effects to a later point in time.

Again, if you'd like us to be way above thresholds, I can manage to do that by tomorrow. I don't even have to spend a minute to list a good chunk of release-blocking issues that are not classified accordingly.

In the end, we, code monkeys, want to get our stuff in. But we don't give a shit about the overall state of Drupal, as long as our stuff lands. In the end, the core issue thresholds prevented core maintainers from doing their job multiple times already. Because they are a community-accepted tool to prevent Drupal being turned into unreleasable crap. In the end, it is the responsibility of maintainers to provide vision and direction, and to take the appropriate measures whenever necessary. Core maintainers are factually exempt from all rules, and they technically do not even have to justify their actions. They have been chosen for a reason.

However, generally adjusting threshold policies for the entire core contributor community has no effect other than further obfuscating reality. That's pointless. And debating it to this length is counter-productive. If you want to bring Drupal 8 into a releasable state (and potentially get your own patch in), fix those critical + major issues. They are only a small fragment of the actual picture anyway.

Thanks!

every time something goes over thresholds, it's motivation to go back and help kill a major once in awhile if I know Views can't be merged in.

I think folks will continue to work on what they are, but also hopefully stop lying about the technical debt they know about because of social pressures.

The critical/major priorities are frequently gamed with, they do not represent the actual state of the system. It would be impossible to release D8 now. Reality is, it would be impossible to release D8 in 3 months from now.

Again, if you'd like us to be way above thresholds, I can manage to do that by tomorrow. I don't even have to spend a minute to list a good chunk of release-blocking issues that are not classified accordingly.

I don't understand why new features that are ready can't just be merged in. That's what pre-feature freeze is for. We have a specific step in our release process designed for cleaning up the release (code freeze), so I don't understand why we're trying to muddy those waters. Merge features now, fix bugs later.

The D7 release was insane - 300+ critical issues after feature freeze (and it might have been more than that...I don't remember) - but at least the number of issues reflected reality. If some amazing person went through and cleared the D8 critical queue right now, there would be a big pile of issues ready to be promoted to critical to fill in the space. This, to me, says that issue queue thresholds are only a community imposed way to distort reality to the point where we don't feel maddened about the amount of work left to do on core before the next release.

Not only that, but they're preventing new features from getting into core during the only time we have to get new features in. It just doesn't make a lot of sense to me.

@cweagans, the number of critical issues against Drupal 7 was absolutely nothing like reality.

I personally closed 5-10 critical bug reports during just one time going through the queue that were duplicates of other critical bug reports - some of which the paired issues were well into dozens of comments, including even the same contributors posting on each months apart.

We also had loads of critical bugs like "no test coverage for contact admin deletion" because in 2008 some of us (including me) decided that Drupal 7 shouldn't release without 100% test coverage - something a few months later we realised wasn't actually a viable/measurably goal, but those issues were still in the critical queue for months if not years. There were also critical/major bugs like "so-and-so function has a silly name".

At the very least, the thresholds now mean that 99% of what's in the critical/major queues is actually major/critical - what they're not doing though is ensuring that we don't have hidden (known) bugs in the queue that are actually blocking a sane release.

I agree with sun, that although this is a good discussion to have it takes away time otherwise spend on actually solving the queue.

The thresholds did one good thing, as catch said we are 99% those things in the queue are actually critical/major. We know there is a percentage in the queue, that should be critical/major but through process managing (bug -> task -> feature request and moving from critical -> major -> normal).

Realistically I assume after code freeze, maintainers will get realistic and promote issues back to the actual priorities and categories. Views will go in creating a whole bunch of criticals and majors and we will spend a good amount of time cleaning all of that up.

I think there are two questions; 1) does raising the threshold allow us to get more critical features in, 2) are the thresholds a realistic count?

1) Yes, given that Drupal 8 as you would download it right now severely lacks features. I'd say lets just raise those thresholds.
2) Probably not, given that there is no consensus at all about this here by maintainers + garderns.

I'd generally be helpful if @Dries @webchick provided some guidance here, so we could just get on with it. There seems to be large a larger discussion about the usefulness of thresholds, which I am happy happens - but won't get you a quick answer on whether to raise or not raise the thresholds.

For the record, @sun, @Bojhan, @cweagans, I posted this issue because two of three Drupal 8 core maintainers had compromised on the proposal in the summary in IRC. It is not my proposal; it was theirs. Unilaterally marking it closed (won't fix)--twice--borders on insulting. Edit: And, frankly, makes me not want to have anything to do with core.

@xjm, I did not won't fix this, and I think it's an important discussion to have. For the record, if the only thing that comes out of this issue is that we raise issue queue thresholds, I will be happier than I am now, but I think eliminating the issue thresholds entirely is the best path forward.

The situation we're currently in is #1805996: [META] Views in Drupal Core is marked RTBC and, barring an act of nature, will most likely get merged sometime in the next week. Given where thresholds are currently at and where they have been for the past several months (typically juuuuuust scraping by between 0-2 below), that's effectively going to end feature freeze on October X, 2012, instead of December 1, 2012. Unless of course we don't mark issues like a11y follow-up as critical, which they rightly deserve to be, since they're a gate. And then we're just lying to ourselves and further obscuring the picture of what it's going to take to get Drupal 8 done.

Our thinking was that raising the ceiling slightly would give us a little bit of breathing room to allow for anyone else at all to get a feature in between now and Dec. 1.

However, Jennifer makes a very good point:

Given that, my guess (yes, it's only an educated guess) is that if we raise the threshold for tasks to different numbers, the number of critical/major tasks will quickly jump to those numbers and then hover there (plus or minus a few)... and we'll have the same problem that we have now, at those new numbers.

I don't disagree with this educated guess at all.

Jennifer's idea of removing the thresholds for tasks entirely is an interesting one. I think that this would definitely give us a much better transparency into where the release is actually at in terms of the delta between now and "done." However, it's breaking the social pact that we agreed to in order to balance shiny pretty with cleaning up technical debt. And it gets worse, because there's also a whole other dimension to this situation. Currently everyone has a vested interest in attacking those issues when they get above thresholds, because it blocks them or their peers from getting cool features they worked really hard on in. Once feature freeze is over, that motivation plummets to near nothing. Beyond the funded teams, we're going to need to figure out how we grapple with that, so we don't spawn another generation of PTSD core contributors. :\

So given the options, I think I'm still in favour of the original proposal, which is to keep thresholds in place, but add some additional buffer room on major/critical tasks given we're only ~40 days away from feature freeze so that the next big "feature + follow-ups" we add doesn't end up stalemating everyone else.

Also, to be clear, I'm just using Views as an example here, not trying to pick on it in any way. I can cite a Spark example as well: #1809702: WYSIWYG: Add Aloha Editor to core. Essentially, any feature that touches the UI in any way is subject to additional gates that most "normal" core patches are not: accessibility and usability. And striving for 100% conformance to core gates before RTBC, while we generally require it for most patches, will almost assuredly cause no UI-affecting features to not get committed at all, because effort needed to achieve perfection here will extend far beyond feature freeze.

IMO, we need a way for the thresholds to be able to deal with the reality that these follow-ups are still critical and important, but we also want D8 to be an amazing release full of end-user-relevant features. This is the only chance we're going to have to push Drupal forward for the next ~2 years. Let's make the best use of this time.

Lets set a timeframe for this issue, like 22 Oktober? So this can have a decision before Views go's in.

I'd like to remind everyone though that postponing A11y & UX issues to after commit, is a great process for putting new stuff into core - it does little to nothing for those teams but put a strain on their resources to commit their time to damage control. I believe the biggest advantage to the original idea of gates, is that we would get people to work together to solve gate problems before commit - because after, people tend to be less motivated.

Anyway, I don't see much reason not to do this - we have little choice if we still want anything UI-wise into core. I am sure jhodgdon scenario will come true, and it will probably cause PTSD for some teams. It seems the way many major contributors now deal with PTSD, is simply to ignore patches in the area's they fundamentally disagree with - even if they do go in, I don't see post-freeze being any different to that.

So lets do it :)

The other thing with this.

By extending the code thaw but not the feature freeze, we've effectively said that we think we need (a lot) more time to fix new core APIs and update old ones to match, beyond what was allocated originally. That's reflected in so many of the major/critical tasks being around 'convert all the things'. This is undoubtedly true - there's no way all those conversions could get done by February.

However we haven't also extended the estimated release deadline yet, which suggests we think the critical bug count isn't going to grow exponentially once things get to around beta stage and it ought to be relatively easy (at least compared to Drupal 7 :P) to put out the final release, even with a longer window for API changes and a shorter window for pure bug-fixing. Sometimes I think this might even be true, sometimes I think it's going to be a nightmare again.

So the question is, if we raise the major/critical task threshold, is there still any realistic prospect of dealing with most of the API-changing critical tasks (and enough of the major ones) that we'll find in the next few months before code freeze (non-API changing tasks could be done right up to RC).

If there's not, then we'd have to admit that the overall timeline of the release is going to shift (and it's definitely true that lingering usability and accessibility issues were some of the hardest ones left towards the end of the 7.x cycle, I'd put accessibility a definite second after the upgrade path).

If adding more features at this point means the overall timeline of the release is going to shift, are we OK with that? If in a year we're here saying "we put Views in core and it knocked back the stable release six months because we let other stuff in as well", I don't think that's necessarily a bad thing at all - usually people complain about Views not being ready in time for the core release, not when the core release is ready itself.

Two things I absolutely don't want to do though:

1. Pretend everything is fine now then have another 18 months-2 years of 'code freeze' fixing hundreds of hidden bugs after stuffing tonnes of features into core. If that happens it's unlikely I'd continue to be 8.x maintainer by the time we get to end of that, I'm still getting over 7.x in that respect. For this reason I'd absolutely not want to ditch the thresholds altogether for tasks.

2. Start feature (or even code freeze, I bet I can find some major/critical bugs against Views to move into the core queue if I spend a couple of hours looking for them) now, just because it suited certain people to commit now rather than in two months.

I tried to think through different options on how to best address this problem. Because there are a lot of advantages and disadvantages to each approach, I tried to create an overview in a spreadsheet. I also suggested some alternative solutions. Alex, Moshe and Angie helped me fill out this spreadsheet but I'd love suggestions or feedback from everyone else. I think a good and complete summary could help guide us to a decision. Have a look at https://docs.google.com/spreadsheet/ccc?key=0AvbmKQVQuVS0dDJ5ak9pT3VoTDF... and share your thoughts.

It's hard to collaborate when we can't edit or comment. I guess you want us to discuss here? I guess another option to add is "Per-gate critical/major's", which is basically the policy suggestion. I think we are already doing that in places, a con to that is that its largely artificial as some of the issues posted in such issues are release blocking, which will mean we need like a release-blocking-counter/tag.

EDIT: Angie helped me add it.

Per-initiative thresholds sounds intriguing. That may help me justify some issues I recently marked critical, as they're critical blockers for WSCCI but someone who isn't working on WSCCI wouldn't understand why. It allows for localized-context.

I wish we'd done that months ago...

Would it be possible to do something like "provisional commits" to Drupal core? (Similar to #1149866: Add Backbone.js and Underscore.js to core and other issues, but for Drupal code rather than external libraries.)

To be eligible for this a feature would need to:

1. Be a standalone piece of functionality. (Views is a good example; it's basically adding a bunch of files to core but not changing existing code.) The idea is that it must be easy to roll back.
2. Be RTBC except for some of the difficult-to-pass gates (usability, accessibility, performance, known critical bugs, etc).

When an issue like this is committed, followup issues would be created for all the specific bugs/tasks that need to be fixed to make it pass the gates. These issues would not count towards thresholds, so they would not be filed with their actual priority (presumably they'd be identified with a tag instead). The feature is considered "provisional" until all those issues are fixed.

People working on the feature would benefit because the code is actually committed to core (meaning other contributors would have to deal with it and ensure their patches don't break it, just like anything else).

However, there would be two caveats:

1. As long as a feature is provisional, no patches would be committed that make other parts of core depend on it. (Example: If someone wants to rewrite the Forum module to depend on Views, that is a patch that could not go in during this time period.) The idea is to preserve the ability to roll the feature back without breaking anything else.
2. If the gates aren't met by whichever XYZ freeze they need to be (in short, if this feature has enough problems that it's going to hold up the release too much), then it is removed from core at that point in time.

I think this would be more effective and more fair than any of the ideas in the spreadsheet. And it would appear to solve the "Views problem" (which may not be the only reason this issue was created, but seems like the most urgent one), plus might help with other efforts too, e.g Spark.

I think the first caveat is the killer. Typically, we don't actually find certain bugs until we start using a new system. That's just the nature of the beast. Eg, until we convert comments to use Views, we won't know if Views' sorting and rendering can handle a Comment vancode-style display. But #34 would prevent us from trying to do that until, say, accessibility concerns in the Views UI are resolved. That basically prevents progress on unrelated parts of the same project (Views in Core).

Yeah I agree with Crell in #35, usually we find hidden major/critical bugs (especially upgrade path, performance issues etc.) when converting things to use new subsystems, so anything which might hold that up means those could be found later. Also replacing old 'custom' code with new stuff is a lot of the content of the major/critical tasks queue so in terms of thresholds as opposed to gates it's going to mean a lot of that integration work gets stalled.

I looked at Dries' spreadsheet but also don't have permission to edit. I have some thoughts on some of the options but not time to type them up properly this morning - it looks like a decent summary to me, although #1410544: Consider possible ways to shorten code freeze [policy, no patch] isn't in there ;)

I am certain that major / critical accessibility issues will not be addressed before D8 is released. I am further confident that the more features that are added to D8 will increase these counts. That's okay, if the community decides to place the value of new features over and above the qualities that Dries announced in the gates in Denver(?).

Perhaps there are good reasons, market share, competitive advantage, etc., that we prefer the features over quality approach. But, it discourages me from wanting to contribute any further to Drupal Core.

I disagree adamantly with the idea that putting Views in core "ends feature freeze", and the suggestion to block our work on this discussion in the 11th hour is short-sighted. Putting Views in core is how we fix Views' accessibility and usability issues. I'm trying not to take it personally, but it's hard when people have started labeling it "the Views problem," when initially this issue had little to do with Views and more to do with the stress that other initiative leads are under.

Also, I'm not sure "per-initiative" thresholds will work, because currently, most significant bugs in Views are actually Symfony or CMI issues, and Views is simply the canary (or maybe ostrich) in the coal mine. It also seems very likely to create silos--"that's a CMI problem so it's not my problem"--and undercuts the strength of the current thresholds, which is that people from initiative X have incentive to collaborate on resolving the issues that "aren't their problem."

Sorry, xjm, I tried to make it clear that I wasn't intending to pick on Views here. #1809702: WYSIWYG: Add Aloha Editor to core is another example that, if added today, would bump us up over thresholds for effectively the rest of feature freeze, due to items outside of our immediate control (namely, upstream bug fixes/accessibility work).

Everett, can you qualify #37? Why do you think the teams rallying around getting these features into core would not resolve any critical accessibility issues they introduce before release? I have so far seen nothing but strong commitments from each and every team to do so.

Also, catch, I added you to the doc. If anyone else wants access to add an idea, just ping me. Dries just didn't want to make this "world" writable for, uh, probably obvious reasons. ;)

EDIT: and David too.

@webchick, I don't understand why adding issues that put us over thresholds now corresponds to "the rest of feature freeze." So Views or Spark adds a critical and a major or three and we go over thresholds. That happens every 2-3 weeks. Our amazing, thriving developer community attacks the problem and we get back under thresholds. Why would this be different? I don't understand the premise. To me the proposal is not directly about adding major new features; it's about keeping initiative leads from jumping off $local_bridge_or_land_formation and about socializing the idea we shouldn't try to hide our technical debt.

Also, if I could have edit access to the doc, that'd be great. The note at the bottom about the Views accessibility meta is misleading; none of the known, filed accessibility issues are critical, to my knowledge. If we discover during that accessibility testing that something in the Views UI is not keyboard-navigable, for example, then I don't see why we wouldn't file that as a critical bug.

Well, for our part, the difference is that we can't close a critical accessibility issue about WYSIWYG in core until Aloha Editor is fixed upstream, which I am not certain will happen in time for feature freeze. That effectively makes it a "perma-" critical task for the remainder of feature freeze, similar to #1775842: [meta] Convert all variables to state and/or config systems which will also (in all likelihood) not be resolved before then.

Views will probably be in a similar place with things like an accessible modal dialog (blocked on upstream jQuery UI), various usability issues (blocked on user testing), etc. Basically, changing Drupal core's front-end in any way is hard. It took us 200+ comments to get #1608878: Add CTools dropbutton to core resolved (and even still it's not resolved optimally and needs major follow-up work) and that is one itty-bitty control. Views UI introduces several more. Each of them will need their own 200+ comment issues to resolve accessibility and usability concerns.

So I'm guessing once we've added another maybe 1-2 front-end facing features, we will effectively be over thresholds for the remainder of feature freeze simply on the "perma"-criticals alone, due to the accessibility and usability gates. This isn't a Views problem. Views is simply the "ostrich in the coal mine," as you put it. :) That's why I think it's important to get some resolution to this question.

xjm: done!

I just added a comment in #1805996-40: [META] Views in Drupal Core that was an xpost with this issue's #42. Maybe Views is in a much more polished state than I'm giving it credit for, but my gut feeling is that whenever we add a large new feature to core (whether Views, WYSIWYG, Layouts, Twig, whatever), that once a larger number of people start hammering on it (which is what's great about moving it from a sandbox and into core, because we want more people hammering on it), that several hard critical issues and many hard major issues get discovered. It happened with WSCCI, and CMI, and every other D8 initiative. It's not a statement that any of these things were done poorly: it's the nature of the software process. The big things that got committed earlier in the D8 cycle had months to work off some of their criticals and majors, but some of their hard ones remain. Whatever the next big thing to land will be (Views is just the one currently RTBC), I think it will be hard to work off enough of the remaining criticals and majors in time to also allow 2 or 3 more big things by Dec. 1.

That said, I think Views, WYSIWYG, Layouts, and Twig are all very important for Drupal, and I'd be very sad if any one of them didn't make it in (there might be others I'm not listing here, these are just the ones on my mind right now). And like webchick, I have faith that the people involved with each of these will stick around post feature freeze to help refine them. So, I like the option of raising our threshholds by some amount each time one of these remaining big things lands.

Much of Views is anything but polished; all I can say is that it's a lot better than it was. ;) But I still think that's a red herring. If we really want Views in core, those issues are already core technical debt. They're just hidden, the same way that the kinds of issues described in the summary are hidden.

To cut to the chase, I think a large part of the concern here is wanting to avoid the following:

"Views going in generated 8 new criticals, and we didn't fix those by freeze, so sorry, Twig, better luck next time!"
"Twig going in generated 8 new criticals, and we didn't fix those by freeze, so sorry, Aloha, better luck next time!"
"Aloha going in generated 8 new criticals, and we didn't fix those by freeze, so sorry, WSCCI, better luck next time!"

Those are all very very bad end-results. Raising the overall thresholds is one possible approach. Per-major-project thresholds is another. Selective exceptions are another. Dries suggested a few others above. I don't know which we want to take, but the underlying concern, I think, is the above distinct possibility.

The problem with #47 is:

and we didn't fix those by freeze, so sorry, WSCCI

The word we and the adversarial relationship is problematic. If Initiative X has criticals that block Initiative Y going in when it's almost ready, people who care about Initiative Y should help with Initiative X. To my mind that's the whole reason thresholds work.

Actually the even bigger problem is the idea that Initiative X is responsible for blocking Initiative Y. The other 230 issues are just as much to blame, so we all can and should care about all of them.

@Webchick, perhaps it is an overreach to say critical. I believe that everyone is doing their best, and committed to the ideal of quality. I also know from experience that quality decreases during rush, and that issues that effect small user groups are the easiest to forget. We still have outstanding D7 major accessibility issues.

@XJM At the very least #1806022: Views' text color does not have sufficient contrast is critical. This is not to pick on Views, it is likely far less of an potential accessibility barrier than things like Aloha in its current form.

If we are running like crazy toward an arbitrary deadline why not just move the line? The entire process of Core development is entirely inefficient today, and would not be profitable if it were a product in a shop, that being said it the loss of efficiency does bring collaboration and inclusion, which is a key value.

I think that some of the initiatives have brought more efficiency than Core development in the past, so we are definitely moving in the right direction. One barrier is the length of the lifecycle, we only get one opportunity to inspect and adapt every 2-3 years, which increases pressure to get things perfect, rather than 80% of the way to perfect.

Care? Yes. Have any ability to do something about it? Not necessarily.

"Sorry Morten, you need to go fix WSCCI routing issues or FAPI bugs if you want Twig to go in, because otherwise you don't get to benefit from the Twig work you've been doing."

That's particularly unproductive since he would have no perspective, ability, or interest in the deep details of WSCCI or FAPI, and is also sufficiently rude that I will not even attempt to quote what his response would justifiably be in a forum where kids may be watching. :-)

I'm not picking on Morten here. I'm pointing out that the "resourcing pressure" aspect of the thresholds only works with Core Generalists. For Core Specialists (Morten being one example, me being another, there are dozens more), it doesn't really work.

And even if it did, "Sorry Morten, Aloha went in so now you have to stop working on Twig and find even more time to go fix Javascript issues" is adding more work to him that has nothing to do with what he is interested in, and pulls him away from the still-in-progress-and-very-important Twig work.

Core devs are not a single unified pool of resources. Yes, we should care about all bugs in theory. In practice? Not everyone cares, or even *should* care. That's simply a fact.

@Crell, you shouldn't go out of your way to spend your time in the general core pool, and I shouldn't spend my time trying to address WSCCI issues, "blah blah DICs blah bundle services blah kernel router blah" etc. :) However, we both get people who are interested in helping with our initiatives, but who don't have the depth of experience necessary to fix the Views UI or the blah blah kernel container bundle register blah. Those are the folks for whom it's worth to spend 15 minutes looking for a low-hanging fruit in the majors or criticals, and saying, "Here, fix this issue and help unblock our next feature." I fixed a critical in five minutes the other day; the slightly more time-consuming part was the tests, but only because I was trying to be a purist. I solved a major I don't care the slightest about a few days before that. It took longer to try to explain the scope of the issue than it did to patch it. WSCCI stuff is hard, but there's plenty of other threshold stuff that's not.

When I wrote "Views problem" above I put it deliberately in quotes (along the same lines as @webchick). It's definitely not just an issue with Views :)

Yeah I agree with Crell in #35, usually we find hidden major/critical bugs (especially upgrade path, performance issues etc.) when converting things to use new subsystems, so anything which might hold that up means those could be found later.

But people could still work on those conversion patches in the interim, couldn't they? It's only committing them that would be held up. So I'm not sure I understand the concern.

In any case, it's also possible to combine some of the ideas above. For example:

1. We could do my proposal in #34, to deal with the issues and issue areas (a.k.a. gates) that we know about but aren't going to fix before a major feature is committed.
2. We could also increase the thresholds when a major feature is committed, to deal with the inevitable issues that we don't know about yet but will discover eventually.

The problem with only doing the second one is that it doesn't help with the accessibility and usability frustrations and defeats the purpose of the gates (as Bojhan said above, it basically reduces contributors in those areas to doing "damage control").

Okay, now that I have been sufficiently reassured that people don't actually think that I filed this issue to try to get some sort of exception for Views (which couldn't be more false), I actually don't hate #34. I'm not sure it's entirely in scope here--at least my concern is with exposing technical debt already in core, and we seem to have gotten away from that in this discussion--but it could moderate some problems that might be exacerbated by Views/Aloha/Twig/New Shiny™ going in.

On the other hand, #34 would be really hard to track. We want Views-related criticals filed properly as criticals so that they're visible, but if Views is "provisional" pending critical accessibility testing and performance issues, does that mean its issues shouldn't count toward thresholds? That means core committers would have to go "Hmm, so 107 major bugs, minus three for views, minus one for aloha, minus two for whatever.js..."

I think #34 means that a Views critical would be filed as normal and tagged "provisional critical"?

Despite this is directly affecting me, I don't have strong opinions. Any of the suggestions in that spreadsheet are better than nothing.

@xjm, great! Yes, that was definitely not what I intended to suggest. Sorry for any misunderstanding.

Yes, I was thinking those issues would be filed with normal priority and a special tag, which is not ideal. However, if we're combining this idea with an increase in thresholds (which makes more and more sense to me) then that's actually not necessary; these issues could just be filed with their real priority as long as the thresholds increase enough to accommodate them. I didn't mention that originally because I thought it would be a maintenance nightmare to figure out how much to increase the thresholds by, and then constantly decrease them again as issues actually get fixed. However, decreasing thresholds gradually is apparently what @catch wants to do eventually anyway (#1410544: Consider possible ways to shorten code freeze [policy, no patch]) so maybe it wouldn't be so bad.

The "Don't count D7 towards thresholds" sounds like a no brainer in the decision.

Guess I should respond to that, as D7 maintainer :) Currently, there are 0 critical bugs, 23 major bugs, 1 critical task, and 4 major tasks open against Drupal 7. So assuming those numbers hold up (probably some of them are Drupal 8 issues in disguise) it would have a somewhat significant effect.

Things I like:

• It allows Drupal 7 point releases and the Drupal 8.0 release to be on their own timelines (which shouldn't have anything to do with each other at all). Personally, when I review and commit patches my goal is to make sure the Drupal 7 RTBC queue gets down to zero before each bugfix point release (because otherwise people will feel like a release came out and their issue was ignored), but I don't really care if Drupal 7 issues sit at RTBC for a while in between (especially the super-complex issues, for which it's not only OK but often a good idea). It's unfortunate if this is preventing features from going into Drupal 8, and no reason it should. (At the moment there are only 3 major bugs and 1 major task in this situation, so it's not a big effect anyway, but there's still no good reason for it.)
• It means Drupal 8 priorities wouldn't affect Drupal 7 patch reviews. For obvious reason, Drupal 7 patches need to go through a more rigorous review process than Drupal 8, but if issues are being moved through and marked RTBC as quickly as possible to help clear out the thresholds, that won't happen (and it often doesn't).

Things I don't like:

• There are good reasons it was set up this way originally (see #1050616: Figure out backport workflow from Drupal 8 to Drupal 7). Drupal 7 is currently installed on 500,000 sites, which is about 500,000 more than Drupal 8. But Drupal 8 features are more fun to work on than Drupal 7 bugs. The thresholds help restore some balance. That's a "negative incentive" for people to work on Drupal 7 issues ("you must work on Drupal 7 if you want Drupal 8 to get new features"), which isn't as good as a positive one, but well, the Drupal community hasn't really come up with positive incentives so that's what we have.
• I have no idea what this would mean for committing features to Drupal 7. (Although the features that are going into Drupal 7 are so small anyway that it always feels silly to say "we can't commit this because we're over thresholds"; they don't really affect much of anything else anyway. So frankly, Drupal 7 could just ignore the thresholds in both directions.)

Overall, I think I'm in favor. Tying Drupal 7 and Drupal 8 progress together made a lot more sense when Drupal 7 was less stable (and when Drupal 8 was more similar to it) than it does now.

Actually, filing a views issue as a critical and then simply tagging it "provisional" would allow maintainers to do a two-step check: click the dashboard link for critical bugs, then filter on tag "provisional" and then it's simply subtraction. Bookmark those four links and it's slightly more tedious to verify if and how much we are over thresholds, but one already needs to check manually when it's close anyway since the block gets cached. Edit: And a quick glance still shows us the total thresholds, so it also helps a bit with the psychological aspect. ;)

The main concern regarding with not counting D7 is stuff relating to the upgrade path: database update system issues and other issues tagged for the upgrade path or issued tagged "D7 upgrade path". Also issues for ensuring the schema matches after an upgrade and that a D6 dump can be upgraded to D8, which I swear exist but I'm not finding right now. Edit: Honestly I'd be okay with counting only those issues and not the rest of D7 issues, but d.o on D6 is not going to let us build a view that complicated. Edit 2: Maybe we add a separate threshold for "upgrade path" that's shared across branches, and standardize how those issues are filed/tagged? Just brainstorming.

I don't want to release Drupal 8 while it's still not possible to do a core upgrade from Drupal 6 to Drupal 7. What 'not possible' means is a bit malleable, but probably most of the existing major/critical upgrade path bugs against 7.x fall under that.

For me this isn't really about thresholds as much (although thresholds are probably the only reason these get fixed, upgrade path issues are not fun to work on), but simply that you can't simultaneously drop support for a release while also not having fixed the upgrade path from it. If you think this is a bit strong, read #895014: All fields of a node type are lost on module disable and the linked issues all the way though.

With removing Drupal 7 from the thresholds, I assume we're talking about bugs as well as tasks. This issue was really only about tasks but I'll cover bugs first:

There's two kinds of issues really apart from the upgrade path:

1. Serious issues in Drupal 7 that can be fixed in a backportable way in 8.x and due to the thresholds get more or less swiftly backported to 7.x. Generally this has worked pretty smoothly the past 18 months, much better than it ever worked for 6.x. Thresholds definitely help get those fixed quicker, and there are still 67 critical/major bugs against 8.x with the 'Needs backport to D7' tag.

2. There are issues like #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap which we have spent more than a year fixing on Drupal 8 and may not be possible to ever fix acceptably in Drupal 7. I gave up working on that issue months ago because I had a working patch that was shot down as a hack with no other alternative given. I could see that issue staying open until Drupal 9 is release but at least it has a link to http://drupal.org/project/registry_rebuild.

For the second type of issue, I don't think it makes sense to hold up 8.x features on issues like that, because we've done our best to fix them, it just required rewriting tonnes of code that we can't backport. For the first category, if we did remove 7.x from thresholds then I'd want to keep an eye on how many major/critical bugs end up stuck at 'to be ported'. Currently it's zero, although some may have moved from that status to CNR/CNW.

With tasks, there's only 21 major/critical tasks tagged with 'Needs backport to D7', scanning through, probably a lot of those aren't really major for 7.x, but that could be handled by downgrading them once they're fixed in 8.x (if that's really the case).

I can't really figure out what 'provisional' would mean in practice at all so leaving that for now.

How about making D7 criticals count towards the thresholds, but not D7 majors?

If an upgrade path issue is serious enough that it prevents people from doing a D6->D7 upgrade without data loss (or is required in D7 in order for D7->D8 upgrades to be possible) then it should be critical anyway, not major.

Well, if all upgrade path bugs are critical, then we are drastically over that threshold right now already. I personally know of several that are filed as major. I have someone working on one for office hours that has a documented workaround.

I think "provisional" in a nutshell means that if Views has critical accessibility or performance regressions Dec. 1, we roll it back.

xjm wrote (#53):

(...) it's worth to spend 15 minutes looking for a low-hanging fruit in the majors or criticals, and saying, "Here, fix this issue and help unblock our next feature." I fixed a critical in five minutes the other day; the slightly more time-consuming part was the tests, but only because I was trying to be a purist. I solved a major I don't care the slightest about a few days before that. It took longer to try to explain the scope of the issue than it did to patch it. WSCCI stuff is hard, but there's plenty of other threshold stuff that's not.

About this way for more people helping to get below the issue thresholds, critical and major issues across D7 and D8 with the "Novice" tag are currently the following:

• Critical bugs (max. 15): 0 Novice issues
• Major bugs (max. 100): 9 Novice issues
• Critical tasks (max. 15): 1 Novice issue
• Major tasks (max. 100): 4 Novice issues

Another issue tag is "Quick fix", used before for even some critical and major D7 issues, but it seems that only on normal and minor D7 & D8 at this time.

I think "provisional" in a nutshell means that if Views has critical accessibility or performance regressions Dec. 1, we roll it back.

I wasn't thinking it would be that early, actually - more like whenever the latest time is that a feature can reasonably be rolled back (somewhere around the first D8 release candidate)?

Although there certainly would be big incentives to finish it earlier.

Just posting an overview of conversation here to spark more discussion:

1) Concerns
a- Critical bugs: 11 of them are a year or more old, which means these items are *really hard* (several are upgrade path issues)
if we don't know how to fix something that is a blocker, we need to figure out at what point we deal with it.
b- Another concern is that these critical features may start adding new major issues, then we're multiplying the work to be done late in the game
c- Read this: http://drupal.org/node/1810428
d- We're setting up rules, then finding ways to work around them
Reducing slush of issues will force people to pick up harder, more long-term issues that have been sitting in the queue for a long time
people are getting all over the easy stuff to get the critical #'s down, but it's not attacking the most urgent issues which may be harder to do.

2) Managing the critical/major thresholds:
a- Triage is going on (anything over a day = has community consensus)
b- Issue summaries: get people to write summaries, especially for critical + hard ones
c- Raising awareness that honest labeling is important
d- Differentiating critical tasks and critical bugs => raising task threshold to allow enough time to "bake" while we add more features
e- IO's need to be good examples for the rest of the community wrt honest tagging
f- Possible increase of critical tasks threshold to 25, keep critical bugs at 15

3) Is the critical bug situation an indicator of feature capacity?
a- On D7 the features slush was a lot longer, and the idea is that if we keep critical issues low enough, then we can focus on keeping slush shorter in d8
b- Dries says: we should focus on the "balance" factor between stability & new feature additions instead of focusing so much on the critical bug threshold
c- Angie says: the point of all this is to make d8 a compelling product
d- What do we say to people who think we don't need to add any extra features? => d8 needs to have newness to have purpose!

What does everyone else have to say about ^ that?

One thing with Drupal 7 issues, if they're RTBC I usually use some discretion and manually subtract them from the thresholds anyway - although they won't always necessarily be 'ready' yet, while they're RTBC there's not a lot that people can do to move them on - so if there's 101 major bugs and one of them is a 7.x RTBC issue, that's close enough.

David's idea of making critical 7.x issues blocking but majors not is interesting.

Since bugs that also affect 8.x will block, then it at least means those will get some kind of fix before they drop out of thresholds, it'd mainly affect backport speed. We could also trial something like this and see how bad the 'to be ported' queue gets after a month.

"One thing with Drupal 7 issues, if they're RTBC I usually use some discretion and manually subtract them from the thresholds anyway - although they won't always necessarily be 'ready' yet, while they're RTBC there's not a lot that people can do to move them on - so if there's 101 major bugs and one of them is a 7.x RTBC issue, that's close enough."

Yeah, I concur with this and do similarly. I'd rather manually do some math than commit patches to D7 before they're ready which end up breaking real life sites. And I also don't want to put the pressure of the entirety of D8's core development team's enthusiasm on David's shoulders. ;)

So, we really need to go back in time a few weeks and get this issue resolved. Failing the ability to travel in time, can we try to get it resolved now? (Or push back the code freeze date a bit? Or something?)

I'm tempted to mark this issue critical, but that would be beyond ironic :)

In the meantime, I've started burning some of the Drupal karma I've built up over the last 5 years or so by going through the issue queue and demoting issues that I don't believe are "major" or "critical" to a lower priority (you can see my initial progress, live from tonight's Rockville Maryland issue sprint, at http://drupal.org/project/issues/search/drupal?issue_tags=major%2Fcritic...). Yes, I realize that kind of thing is sort of what this issue originally wanted to stop, but there isn't much other choice, and in any case, I think I've been legitimately finding issues that were prioritized higher than they should have been... at least so far.

Got a second wind and we're now under thresholds again (barely, and only for the moment). But it didn't feel like a great use of my time.

To recap the combined proposal(s) here:

1. Raise the issue thresholds when a big new feature is added to core (or at this point, just raise them).
2. Treat a feature as provisional if it's committed without passing the "gates" (otherwise, the "gates" are meaningless and the thresholds just a game).
3. Don't count D7 major issues towards the thresholds.

(Regarding #3, it's good to hear that @catch and @webchick already do that informally for RTBC issues, but I think it would be simpler to just do it for all issues, especially since many RTBC issues I've come across lately really, truly still needed review/work anyway...)

#71 @earnie As the author of that issue, and after reading David_Rothstein's response I am hesitant that using a tag or status would become some sort of political wedge (I feel there are other tags in existence that already have a slant and I don't support this). Specifically to that issue, I am somewhat new to contributing to core and so am not yet completely familiar with the conventions of criteria threshold, so I want to glean more via this present issue and other documentation. I'll follow-up on #1831998: Reduce index.php for easier upgrading later today. :)

Yes, I realize that kind of thing is sort of what this issue originally wanted to stop

I disagree with that. Thank you for demoting things that aren't actually major or critical. It's very useful for the critical and major queues to reflect reality, by:
- kicking normal issues out of them, and
- not demoting, or stopping escalation of, issues that should be escalated.

To the extent thresholds encourage the former, they're working. To the extent they encourage the latter, they're not. Sadly, it's very hard to encourage the former without also encouraging the latter.

I partially agree with @effulgentsia, but then again not.

Fact is, we do not have a definition of what exactly constitutes a critical task or a major task. The Priority Levels handbook page does not say anything at all about critical tasks, and the major priority for tasks is defined as a "community decision". (But what exactly does that mean? Votes? Sufficient buy-in from long-term contributors? And how is that expressed?)

Thus, @David_Rothstein indeed burned some of his karma by demoting one of my biggest pet peeves, #575298: Provide non-PHP way to reliably override CSS, to a normal priority, since there is a clear community agreement that there is a functional design flaw, which has to be corrected. But, at the same time, I can't blame @David for doing that ;) since the rules for critical/major tasks are undefined and too vague in the first place. Due to that, I also cannot really go in and revert that priority change, since, well, on what, exact, ground?

Overall, I've the impression we're wasting a lot of precious contributor time on this. I'm slowly but certainly and very reluctantly reconsidering my position and may have to admit that the thresholds have been a good exercise, but are ultimately the wrong tool for the job and should be removed. Doing so will leave an operational gap. But it's always better to admit when there is no good and definite answer and solution for something, instead of retaining a previous answer forever and pretending that it wouldn't be flawed.

One possible and straightforward way to "replace" them would be to apply human core maintainer/committer sense instead; i.e., when it simply feels like we're having too many problems, state so, and deny to commit new major stuff that would likely add even more to the existing debt. That's neither transparent nor traceable, but in the end, it is one of the main duties of every project/code maintainer either way. Comprehensible decisions will be respected.

That, at least, would make sense.

Given Drupal's size, and that none of our committers are dedicated full time to issue tracking/curating/committing/getting-a-gut-feel-on, I don't know how well #74 would work. This is a natural outgrowth of Drupal's highly decentralized nature. We need some way to define "hold on, time to pay down some debt first"; Thresholds are arbitrary and easy to game. Dries just "knows it when he sees it" doesn't scale. "Someone important decides it's time (for some undefined definition of important)" is just begging for even worse bikeshedding. Dividing the system up so we don't have more than X debt per portion of the overall system could work, but only if we have a system that divides cleanly and enough institutional trust to give some people Dries-level of trust within certain boundaries. We currently have neither.

I don't have a good solution here, unfortunately, but that's really what we're getting at: A mechanism for controlling code debt in a large system.

It's time to move this to critical. Changing the feature freeze date helped, but not really since we're still way over thresholds and have been for a long while (and are far enough over that finding a few issues to demote isn't likely to help much). Meanwhile, the current situation is clearly burning people out (see some of the above comments in this issue).

I'm in favor of @sun's proposal in #74 as an initial step. It's not perfect (and it doesn't really address the root problems) but I think it's an improvement over the current situation for the following reasons:

1. The thresholds are already being ignored when committing certain Drupal 8 features. Unless I'm missing something, this is happening on a regular basis. Clear, recent example: #1824500: In-place editing for Fields. Several other recent examples at http://drupal.org/project/issues/drupal?status=2&categories=feature&vers... as well (for the latter ones, maybe some were on the boundary between feature requests and tasks? - but that just illustrates how arbitrary this all is anyway). We shouldn't have "hard" thresholds but then ignore them at random times.
2. I believe I should be ignoring the thresholds when committing small Drupal 7 features also. (And almost have already, although I think not quite.) More on that below.
3. Core maintainers can look at other indicators of overall code "health" beyond the public major/critical issue counts. By which I mean, security issues. It makes no sense that we have these thresholds but that work done to fix security issues doesn't "count" towards bringing the critical issues down (and actually even does the opposite, since as soon as a security issue is fixed in Drupal 6 and Drupal 7, it appears in the public issue queue for Drupal 8 and only then counts against the thresholds). This is backwards. However, since core maintainers do have access to see the current number of open issues on security.drupal.org, they can keep an eye on that as part of looking at the overall code quality, and on rare occasions can even (privately) say "Hey people in MAINTAINERS.txt; there are too many reported security issues in Drupal core right now, so we really need you to work on some" as part of a decision about committing new big features to the codebase.

As for Drupal 7 specifically, I was asked about this so will explain my point of view here; a lot of this applies at least partially to Drupal 8 also. Basically, I've come to believe I shouldn't pay much attention to the thresholds when committing (small) features to Drupal 7 because:

1. Hey, if Drupal 8 is ignoring them (see above), why can't Drupal 7 ignore them also? :)
2. If you believe that the point of the thresholds is to avoid adding things to the codebase that will increase the major/critical count during times when it is too large already, then consider that (a) small, limited features are very unlikely to cause major/critical followups, (b) that's especially true for Drupal 7, where we expect (hope!) that patches have been tested and reviewed very carefully before we commit them, and (c) in the event that someone does find a major/critical issue after commit, then as long as it's discovered before the next Drupal 7 point release the first step would be to roll back the original patch anyway. So overall, the chance that a small Drupal 7 feature leads to new major/critical followup issues is very small, and I don't see the point of applying the thresholds to it for that reason. (And a lot of this reasoning, although not all of it, applies to small Drupal 8 features too.)
3. Conversely, if you believe that the point of the thresholds is to apply social pressure to "encourage" people to work on important-but-less-glamorous bugs rather than shiny new features, then (a) consider whether that's really a good way to encourage contributions :) and (b) it's simply not fair to expect this of contributors until we resolve the root causes and other quality-related issues (gates, etc.) that have been discussed previously in this issue and are largely being ignored. Otherwise, what happens is that people who are less willing (or less skilled at) saying "let's leave this problem for a followup issue" have to work on the followup issues created by the people who are more willing/skilled. I don't think it's anyone's intention for things to work that way, but it is the effect. As much as I can, I do not want to contribute to that - especially for someone who is just trying to contribute to Drupal by adding a small feature, who has already followed the correct procedure and gotten it into Drupal 8 and is now just trying to backport it to Drupal 7 so they can use it on an actual website today... it seems beyond unfair for me to tell them they have to wait for totally unrelated issues to be resolved before I can commit their patch. So I really don't want to do that for Drupal 7 any longer, and again, I think this partially applies (though not as strongly) to Drupal 8 also.

So wouldn't be the only viable cure to actually enforce the thresholds? I mean, saying: well, we committed a lot of stuff and a lot of threshold debt has been piling up. So now, for a while, please everyone solve critical issues else you won't get your stuff in. In fact, nothing at all will get it.

Other alternative: just not care about that and have a similar (though hopefully better) situation like in D7 when code freeze really strikes: having a wall of critical issues that will delay the D8 release for sure.

I am seeing that getting new and cool features in is just too tempting and fully understandable. But this comes at the cost of heavy critical issue backlog. So if there are thresholds, they must be respected somehow, else they could be completely abandoned, in that I am with @sun and I read David similarly.

It is a simple, yet obviously very hard issue for Drupal: decide whether the priority is to get D8 out on time (whatever that may mean), or to stick to the old "it's ready when it's ready" mantra. You really cannot have both, the dev power is always limited. I am seeing rather the latter. This is fine, but everyone should be realistic about it.

eigentor: Yes, when you have no control over your resources then any sort of planning and scheduling is pathetic at best and useless at worst.

The problem with a hard-block on new features based on criticals is that it assumes interchangeable resources. "Sorry SCOTCH, I know you and WSCCI have been working on getting X feature in for 2 years but it missed the deadline by 3 days because of critical bugs in FAPI, you should have gone to fix those." Well that would be fine if Kris or I had any clue how to fix critical bugs in the guts of FAPI, which we don't. Even if we had the time or inclination we'd be useless on those sorts of patches. If we end up in that sort of situation, that's a superb way to drive away top contributors. (Similar for any other major initiatives or core systems; should a critical bug in DBTNG on Postgres block CMI from getting work done? Like Greg knows anything at all about DBTNG on Postgres?)

Hard and fast thresholds only work on core generalists. It doesn't work as well for specialists, who by nature cannot go work on "whatever needs work".

@David: I didn't commit anything in the list at http://drupal.org/project/issues/drupal?status=2&categories=feature&vers.... I would have committed the Contact conversion because it was a CMI conversion (albeit a radical one) and hence contributes to fixing a critical task, but probably nothing else in that list. It's well known that no core maintainers are consistent about what they do and don't commit and I don't really have an answer to that (i.e. you've spotted issues in bug fixes to 8.x that I committed then moved to backport for 7.x, but that's a good thing too).

I'm confused about your comment on security issues. Drupal 7 had security issues from Drupal 6 in the public queue for up to a year at a time, because there were no tabs kept on the critical bugs at all (until we hit beta) so they were just buried in all the other crap. Having them contribute towards thresholds means they actually get fixed, with test coverage, within some kind of reasonable time frame most of the time.

I do agree that this doesn't really apply to Drupal 7. When we originally added features Drupal 7 wasn't really accepting any features at all so it wasn't discussed in the slightest - only that critical Drupal 7 bugs should contribute (because at that time we'd just fixed a one year old upgrade path that deleted all your comment bodies irreplaceably, six months after 7.0 was released). Drupal 7 has since opened up a lot and I don't think this has really been discussed. IMO if a feature is small enough to commit to Drupal 7, then it's not really a 'feature' as such (more of an enhancement).

@Crell, I couldn't disagree more with your post. It's never been the case that a specific core bug holds up a specific feature (unless there's a direct dependency). Part of the original idea of adding thresholds was to avoid the situation with Drupal 7 where if you continue to add feature after feature without clearing out the bugs that they create, then you end up with code freeze over-running by 18 months.

Three of the critical bugs in the queue right now are directly related to WSCCI and SCOTCH work for example #1872522: Compiled data in PHP storage is cleared too late in drupal_flush_all_caches(), #1848998: Problems with update_module_enable() and #1854902: Document possible CSRF vulnerability in REST module (and about the same for Spark-related features and CMI too). If and when the blocks as plugins patch is committed it's going to add many more. It's not fair to keep adding code that causes critical, hard to fix bugs, and leave them all to the end of the release cycle when only the most hard-core masochistic contributors are prepared to still look at them.

Some of the others are upgrade path related bugs from Drupal 7 which were only discovered months after that release because we spent over a year with a broken, untested, upgrade path which then took a further year or so to get to a working-enough state to release, except that it had critical data loss issues which were stuck in the queue RTBC for months while features were being committed to Drupal 8.

I'm personally very happy that we're hovering between 10-20 known issues of this sort most of the time as opposed to the 200 or so that I spent months of my life trying to fix so we could release Drupal 7, not interested in going through that again (although there's no guarantee we won't of course).

Not sure if this is relevant/possible even, but could we not add an additional priority for change notices. I do not see why they are in the critical state.
I understand the importance of them, and the priority, just wondering if we could not get them into a 'Notice' priority. Then move that as higher then critical to make them easier to see and find, whilst removing them from critical.
I can also see a lot of 'meta' issues in the critical list. Either that would make all the sub issues critical also, or they should be demoted to major. I am particularly thinking of #1757550: [Meta] Convert core theme functions to Twig templates which IMO does not constitute a critical issue. It would not hold up the release of D8 tomorrow, it is a feature many of us want in, but D8 would function without it.
Maybe I am misunderstanding something, so ignore me if you wish.

P.S. why does a policy discussion count as a critical issue?

Also, I have on November 27th, got #961508: Dual http/https session cookies interfere with drupal_valid_token() green, it works and fixes a critical bug. It is also critical for D7 and urgently needs a backport. No one has reviewed and marked as RTBC due to #335411: Switch to Symfony2-based session handling being seen as the better solution for D8. However whilst we hold back waiting for that to get in, D7 suffers, and would not be fixed by the newer D8 change anyway.
IMHO the best route to go, would be to commit the original patch that I helped on it's way. Get the backport for D7 fixed (needs tests adding) and committed. Then, if and when the new patch is ready we just revert the changes from older patch. If the new does not fly, then we are still good to go for D8 also.

@catch:

I think @Crell has a point when he speaks about resources not being interchangeable: in the last days I tried to find some issues to work on in the critical/major queues just to unblock other unrelated work of mine. It was hard for me to find issues where I felt I could give some concrete help (review/write code, provide feedback) mainly because I am a core specialist and most of the issues out there are outside my knowledge area. Obviously I could start reading all the comments carefully and thoroughly study the involved subsystem and the proposed patches, but this would take me a lot of time, where instead people already knowing the matter would probably be far more useful in far less time. I'd be actually wasting time that could be better used to work on things that I know well.

OTOH you have a big point when you say that we cannot leave things out of control and I think the threshold idea is totally the way to go, since it forces us to take responsibility for the consequences of the changes we bring on, i.e. pay our code debt. In this light I'be totally against raising our thresholds because I fear that the critical/major queues would be quickly filled up with new issues in a snap. And we would be back to the same problem, just with more code debt to pay.

I think the responsibility concept is key here: we could move from global thresholds to per-subsystem thresholds. I think this would help for some reasons:

• if I know that my work is blocked only on other work of mine, it's easy for me to prioritize my efforts and keep things running;
• this prevents my work to be blocked by other people's work that may have different priorites than mine: the only thing more frustrating than seeing an issue waiting for feedback for weeks is to keep rerolling an RTBC patch that cannot be committed;
• this removes conflict of interests: while reviewing a critical issue concerning the upgrade path, I was not able to complete the upgrade for a couple of reasons that made me write some quick and dirty fixes. I did not even try to see if I was doing somthing wrong or if there was already an issue for those problems, because I didn't wan't to increase the number of critical issues; I feel like a fool to behave like this, but opening two criticals to fix one would be rather silly too, since I was trying to unblock my issues.

To keep things fair I think we could not have equal thresholds for each subsystem: the main reason why the language system has no critical bugs right now, while the base system has the 25% of them, is not that I am a better maintainer but that usually base system stuff is trickier. Hence we could negotiate a threshold for each subsystem over which only critical/major bugs/tasks are committed for that subsystem.
Another reason for this is that I don't think all the issues have the same importance towards the final goal of releasing D8: we are moving towards a (hopefully) well-defined product, hence priorities can and should be applied to the proposed changes. And I say this against my interest because I realize a working routing system is far more important that making i18n-ready every single inch of core.

We could still keep a looser global cap to ensure some level of cooperation: a maintainer might be overwhelmed in a particular moment and need help from folks from the other areas, but this should not be the rule as it impacts negatively on our overall efficiency.

Responding to #76 a bit...

- I think you meant "Dries, the project lead of Drupal, is committing features that he deems strategically important to the release during feature freeze extension, which at times means ignoring thresholds." :) As is his right. But this certainly isn't a wide-spread phenomenon. I know I haven't committed a feature since before feature freeze, but I do reload my dashboard several times a day hoping for a chance. :D

- I don't really understand why we would count D7 issues against D8's thresholds but not vice-versa. If we want to say that at this point in the release cycle we're going to divorce D7 from D8 entirely and let D7 sink or swim on its own merits so D8 developers can stay focused on D8, then let's have that discussion. But a one-way relationship doesn't really make sense to me.

- "Less skilled" people have actually done great work with the threshold issues throughout the release. They've help triage the queue to remove bogus reports. They've written test coverage. They've tested and re-rolled patches to keep issues moving. This federating of responsibility for technical debt is the entire point of thresholds, and I've observed it happening several times (albeit not really since feature freeze, though). There are very few critical/major issues where you have to start from scratch as a "more skilled" contributor to make a difference.

Now, what is true is that we're over thresholds by enough now that I think a lot of people don't see a hope of getting their features committed, so the incentive to share this responsibility has gone down sharply, and continues to go down for each issue added (and the holiday season doesn't tend to help here). But I think the solution to that is probably more like a "sprint" of sorts on the threshold issues, rather than just saying "oh well, we don't care about how much debt we're piling up anymore" because pretty soon we'll be in hardcore bugfest slog and the fewer intractable issues we have going into that, the better off we're all going to be.

Responding in semi-reverse order:

I think you meant "Dries, the project lead of Drupal, is committing features that he deems strategically important to the release during feature freeze extension, which at times means ignoring thresholds." :) As is his right.

Well, I didn't want to call him out specifically without first knowing his motivations. I mean, maybe he's done it by mistake because he forgets to check the thresholds sometimes - he's a busy guy after all :) If the thresholds are ever ignored on purpose, though, I see that as a bigger problem. There's nothing about exceptions at http://drupal.org/node/1201874 or in the (very long) discussion at #1050616: Figure out backport workflow from Drupal 8 to Drupal 7 that I remember, and introducing them arbitrarily is not a good thing.

I don't really understand why we would count D7 issues against D8's thresholds but not vice-versa.

I don't think we should. But most of what I wrote in #76 applies to D8 as well as D7, and the parts that don't apply could if we wanted to. (For example, we could say that D8 features can still be committed when we're over thresholds, but will be subject to much higher standards of review during that time. That might even make sense.)

"Less skilled" people have actually done great work with the threshold issues throughout the release... There are very few critical/major issues where you have to start from scratch as a "more skilled" contributor to make a difference.

You listed that as a response to my comments in #76, but I don't see how it's related. Maybe you were actually responding to other comments that came after mine? In any case, I agree with you completely :)

But I think the solution to that is probably more like a "sprint" of sorts on the threshold issues, rather than just saying "oh well, we don't care about how much debt we're piling up anymore"

@sun's proposal in #74 does not suggest that we stop caring about code debt. And it also allows for "sprints" like the one you describe. The difference, I think, is that a sprint which managed to fix (let's say) 3 very-hard-to-crack critical issues that everyone was really worried about might be treated as an equal "success" compared to a sprint that instead fixed 30 easier-to-solve problems. Whereas now it wouldn't be.

---

I'm confused about your comment on security issues. Drupal 7 had security issues from Drupal 6 in the public queue for up to a year at a time, because there were no tabs kept on the critical bugs at all (until we hit beta) so they were just buried in all the other crap. Having them contribute towards thresholds means they actually get fixed, with test coverage, within some kind of reasonable time frame most of the time.

My point is that they can currently sit on security.drupal.org in the same state (not fixed, and not counting towards thresholds). Meanwhile, the critical bugs still exist in Drupal's codebase. @sun's proposal has the side benefit that if that ever starts to happen, it does provide a way for core maintainers to "force" them to get more attention.

---

In this light I'be totally against raising our thresholds because I fear that the critical/major queues would be quickly filled up with new issues in a snap. And we would be back to the same problem, just with more code debt to pay.

I think the responsibility concept is key here: we could move from global thresholds to per-subsystem thresholds.

Given the number of subsystems, I think this would naturally require the overall thresholds to be raised anyway. Plus, it would get complicated (and in the end, the whole Drupal release does get held up either way regardless of where the bugs are) :)

---

I can also see a lot of 'meta' issues in the critical list. Either that would make all the sub issues critical also, or they should be demoted to major. I am particularly thinking of #1757550: [meta] Convert core templates to Twig which IMO does not constitute a critical issue. It would not hold up the release of D8 tomorrow, it is a feature many of us want in, but D8 would function without it.

I think that issue (and many meta issues) are marked critical because the conversion is already in progress (some parts of it have been committed) but not finished, and one way or the other we don't want to release Drupal 8 with something that is only halfway-implemented. Nonetheless, I think you are right that in principle all the sub-issues could be critical too (and the only reason they aren't is because that would overwhelm the thresholds).

Also, I have on November 27th, got #961508: Dual http/https session cookies interfere with drupal_valid_token() green, it works and fixes a critical bug. It is also critical for D7 and urgently needs a backport. No one has reviewed and marked as RTBC due to #335411: Switch to Symfony2-based session handling being seen as the better solution for D8. However whilst we hold back waiting for that to get in, D7 suffers, and would not be fixed by the newer D8 change anyway.
IMHO the best route to go, would be to commit the original patch that I helped on it's way. Get the backport for D7 fixed (needs tests adding) and committed. Then, if and when the new patch is ready we just revert the changes from older patch. If the new does not fly, then we are still good to go for D8 also.

Agreed completely; and that's actually exactly what we're supposed to do per http://drupal.org/node/767608. In the case of that issue, though, I'm guessing the reason it hasn't been marked RTBC yet has less to do with the related D8-only issue and more to do with the perceived complexity of the bug (any issue title that refers to "dual http/https session cookies" sounds pretty scary) so very few people really feel confident reviewing it... However, the patch looks simpler than the issue title sounds, so I'll try to take a look later today :)

P.S. why does a policy discussion count as a critical issue?

I think it's critical to resolve this because of (a) comments such as #37, #29 and others showing that the current situation is very frustrating and demoralizing for some very active core contributors, and (b) the fact that we've been over thresholds for a long time now which is having a real effect on the features that can actually get into Drupal 8.

@sun's proposal addresses the second more than the first, but it's a start. (Other ideas have been proposed above that would try to address the whole problem, but it's been a long while and so far not much traction there.)

catch: As plach said, it's not that I'm against mechanisms to keep code debt down; that's a perfectly reasonable goal and thresholds are a reasonable stab at doing so. It's that while one effect of it is "sorry, person X, you have to fix this other bug before you can add a new feature" (which is arguably fine), it also has an effect of "sorry person Y, you have to wait around for person Z to fix this other bug that you don't know a damned thing bout before you can add a new feature" (which is very demoralizing). The former applies more to generalists and the latter to specialists (to use the terminology that I believe webchick invented).

I'm not saying we eliminate thresholds; keeping our code debt low is a good thing. I'm putting them in perspective that they do have a frustrating effect on morale in some cases. I recall when VDC went in, one of the big concerns was that it would create a number of critical/major follow-ups as splash damage and grind all of the other initiatives to a halt. I don't believe that happened (yay!), but it was a serious concern. A similar question recently came up with the Blocks patch.

I don't know what the best solution is. I'm just highlighting one of the impacts that it has.

@David_Rothstein:

Given the number of subsystems, I think this would naturally require the overall thresholds to be raised anyway.

Well, not if some of them are not allowed to have even 1 critical bug without triggering a subsystem feature freeze. For instance, I'd be totally ok with having a 0 critical threshold for the language system and the language module.

Plus, it would get complicated

I agree this would make committer's work harder, sure, but having a slightly lower commit throughput might be a worth tradeoff, when the alternative is leaving out many good features or alienating contributors.

(and in the end, the whole Drupal release does get held up either way regardless of where the bugs are) :)

What this does not take into consideration is that, if this situation lasts for other two months, all the features that I've been working on in the last month will be rejected just because other areas of core are not in an ideal shape. This would be unfair.

@Crell You are right, I have largely kept from commenting on this thread because I am kind of in a unique position not contributing any code. But it is a downer - when usability improvements do not go in, because a number of highly technical issues are keeping the thresholds high that I can do really nothing to help out on, I've tried - but there is little I can contribute.

I am not so much concerned with the very real effects on D7 dev, it seems like those are valid and should be addressed. I am more concerned with all the side effects, of the readjusting of categories/priorities/grouping just to get below those thresholds. Sadly, usability issues are often the victim of that. We now have tactics such as 1) grouping critical issues under a [meta] issue, 2) demoting issues to major, because usability issues cannot be critical 3) endless re-categorization of issues by people with different standards. All the side effects trouble me more, than the occasional patch that doesn't go in. Because we don't get a clear picture, which issues need to be solved before release - and maintainers like me are discouraged, to actively speak up for the UX problems I see need to be fixed before release - as I am trumped with a "you don't want to hold of someone else his feature".

I recall when VDC went in, one of the big concerns was that it would create a number of critical/major follow-ups as splash damage and grind all of the other initiatives to a halt. I don't believe that happened (yay!), but it was a serious concern.

I agree the VDC team has done a fabulous job in addressing their follow ups, and thereby, keeping their impact on thresholds quite a bit lower than I expected. However, it is currently contributing to 3 of 103 major bugs and 4 of 109 major tasks, so it's contributing a not insignificant percentage of our overage. There's no reason to pick on VDC though: CMI is contributing to 7 major bugs and 10 major tasks. Both were valuable features to include in Drupal, and both have follow up work: that's as it should be.

I think the responsibility concept is key here: we could move from global thresholds to per-subsystem thresholds.

One small step towards this that wouldn't require any new reporting capabilities on drupal.org is that if a feature request is for a component that has 0 critical or major bugs or tasks, then to allow it regardless of global totals. The potential downside of this is that a feature to component X could create follow up work for component Y (e.g., the "base system"). However, the upside is that it makes some small features in easier reach. Want an improvement to language.module? Great, finish the 1 language.module major task currently in the queue, and you can have it. This could help with morale and empowerment, and thereby, result in greater total contributions towards clearing out our majors and criticals. Note that of our 10 current RTBC feature requests, only #209672: Use site name in From: header for system e-mails satisfies this condition.

One small step towards this that wouldn't require any new reporting capabilities on drupal.org is that if a feature request is for a component that has 0 critical or major bugs or tasks, then to allow it regardless of global totals.

This sounds quite good to me as a stop gap fix :) +100

The potential downside of this is that a feature to component X could create follow up work for component Y (e.g., the "base system").

Yes, we cannot enforce responsibility everywhere, although we can put some "social" pressure on people disregarding follow-ups in other queues.

Note that of our 10 current RTBC feature requests, only #209672: Use site name in From: header for system e-mails satisfies this condition.

Yes, it seems I have something to work on, although the following two, which are the only ones belonging to components I'm responsible for, entered the major task queue only after my first post :)

#1833022: Only display interface language detection options to customize more granularity (just promoted)
#1810386: Create workflow to setup multilingual for entity types, bundles and fields (was RTBC)

- I think you meant "Dries, the project lead of Drupal, is committing features that he deems strategically important to the release during feature freeze extension, which at times means ignoring thresholds." :) As is his right

If it's his right to do that, then it's everyone else's right to call him out on it if they disagree.

Any feeback about #88?

I'd be fine with #88, probably with the exclusion of features that have known major/critical followups when they go in.

Sounds reasonable to me.

+1 to #88. Sounds like a very reasonable adjustment with no downside.

plach wrote (#82):

I think the responsibility concept is key here: we could move from global thresholds to per-subsystem thresholds.

effulgentsia wrote (#88):

One small step towards this that wouldn't require any new reporting capabilities on drupal.org is that if a feature request is for a component that has 0 critical or major bugs or tasks, then to allow it regardless of global totals.

catch wrote (#92):

I'd be fine with #88, probably with the exclusion of features that have known major/critical followups when they go in.

So, a zero-threshold way out? Scratch your own component's itches... That seems indeed something people can more effectively do.

So the proposal is basically to allow features to be committed while over thresholds, as long as there no major/critical issues in the subsystem the feature touches, and as long as the patch is held to a higher standard of review?

I agree this couldn't hurt, and for some subsystems is even likely to help... so sure, why not :)

But I don't see it as fixing anything for a lot of areas of core, some of which are interdependent on each other, and some of which maybe already had a big feature committed and are working off the followup major/critical issues for that and will be for a while (but there still may be other features that people are working on that are in the same area but aren't even closely related... we have some big "subsystems").

Also, how would this work for something like #1841788: Add project browser which is proposing the addition of an entirely new module (i.e., the "subsystem" it will be in doesn't even exist yet)?

Also, how would this work for something like #1841788: Add project browser browser which is proposing the addition of an entirely new module (i.e., the "subsystem" it will be in doesn't even exist yet)?

Could'nt we apply the same logic of #88 here? If the new functionality is enough self-contained (and it should) and the reviewers/committers don't foresee a big impact on the critical/major queues it could be committed, otherwise it would wait for things to get back in control. For instance I think that with these policies the REST module would go in even if we were over the thresholds at the time.

If we went to this we'd need to sort out our subsystems a bit. The component list for core at the moment is next to useless.

For brand new features like REST module then it'd be a case of how many known critical/major issues they introduce going in and/or making the commit provisional -i.e. if it looks like it'll end up contributing to release blockers be prepared to roll it back out to contrib.

If we went to this we'd need to sort out our subsystems a bit. The component list for core at the moment is next to useless.

Do you mean we should revisit our component/dependency map?

For brand new features like REST module then it'd be a case of how many known critical/major issues they introduce going in and/or making the commit provisional -i.e. if it looks like it'll end up contributing to release blockers be prepared to roll it back out to contrib.

Yes, this sounds as a natural consequence.

If we went to this we'd need to sort out our subsystems a bit.

That would be a great thing to do, however given the number of core components (systems, modules, etc.) and their interdependences, it's a task that probably would take more time than the now available for D8.

Anyhow, surely it would be needed if, later, subsystem thresholds greater than zero were going to be established. If I understand correctly, effulgentsia's zero-threshold in #88 was proposed as a temporary workaround using core components as they are now.

It could be tried for a time to see if it helps to reduce the global numbers, as said via people's motivation to get awarded a way out from the global thresholds, after they diligently scratch their own component's itches:

One small step towards this that wouldn't require any new reporting capabilities on drupal.org is that if a feature request is for a component that has 0 critical or major bugs or tasks, then to allow it regardless of global totals. The potential downside of this is that a feature to component X could create follow up work for component Y (e.g., the "base system"). However, the upside is that it makes some small features in easier reach. Want an improvement to language.module? Great, finish the 1 language.module major task currently in the queue, and you can have it. This could help with morale and empowerment, and thereby, result in greater total contributions towards clearing out our majors and criticals. Note that of our 10 current RTBC feature requests, only #209672: Use site name in From: header for system e-mails satisfies this condition.

Yes, isn't there really a way to get an RTBC on #88? If fixing this (in any possible way) is going to take more than 2/3 weeks I'd say we can just won't fix it and clean the critical task queue up a bit :)

We're currently close to being under global thresholds again, so I don't think this is critical at the moment, but will be again once #1535868: Convert all blocks into plugins is committed. So, postponing this for now, but assigning to Dries for comment.

I've started to look into this. I want to work on this with Angie and catch so it may take us a couple of weeks to have a first proposal.

Over again. Unpostponing.

While we're still waiting on Dries, catch, and Angie to figure something out, I just wanted to post some new data related to #88. This isn't intended to start a new round of comments: it's just to provide a data point snapshot.

We're currently 10 critical bugs, 10 critical tasks, and a couple major bugs and tasks over thresholds. The couple majors are part of normal fluctuation and aren't a big deal, but the criticals, especially the critical bugs are concerning. I'm confident we can work them down with time, but if the thresholds are intended to nudge attention and resources towards dealing with criticals, now is the time for that to be happening.

Meanwhile, we have 7 RTBC feature requests (that number may change by the time you read this). If we want to hold all of them up on fixing 10 critical bugs and 10 critical tasks, we might be holding them up a while. On the other hand, if we wanted to do something like #88, then that wouldn't really help the configuration system or node system issues (if you lump node.module and "node system" together as a single component), but it would green light the text.module issue, and put the rest.module, translation_entity.module, and views.module issues within easier reach, provide some reward to working off those few majors, but not really nudge any further attention to the criticals.

Adjust major and critical task thresholds during code thaw

With second feature freeze around the corner, this issue is obsolete.

Thresholds do not apply anymore, since our entire resources and energy will focus on resolving the bugs, gaps, and inconsistencies to get D8 out of the door.

Let's revisit this policy for D9 (in 2014 or 2015).

I mostly agree that time and inactivity have run this into the ground for Drupal 8.

However, there is still a week left before feature freeze, and I'd really like to know the answer to this simple question:

If I try to help get one of my favorite features into Drupal 8 over the next week, does it still have a chance of getting committed?

(Frankly, the amount of time left at this point - given how long we have gone without knowing that - makes it unlikely anyway, but there's a chance.)

The policy says no - to my knowledge we have been over thresholds (and mostly very far over thresholds) for well over two and a half months now. However, as I described in my comment back in December (and which has become even more true since then), the reality says yes/maybe. Many features have been committed to Drupal 8 over that time period, despite being over thresholds. I have no idea why some get committed and others get held back.

At a minimum, I'd like to see http://drupal.org/node/1201874 reflect the reality of what has been happening the past several months. (We don't have to debate it, just make it reflect reality.) And then, make sure everyone knows the reality. So people know what they should spend their time on.

After that, move this issue to Drupal 9. And hopefully in Drupal 9 it will take less than four months to figure out if we can add features to our software or not. There are other projects out there that go through an entire major release cycle in less time than that. Seriously...

Of interest for the Drupal 9 discussion (and particularly on the topic of core gates and how we wind up over thresholds by not following them, as well as the related frustrations expressed above by Everett, Bojhan, and others):

http://www.tsvenson.com/blog/2013/02/dont-make-drupal-the-new-microsoft-...

I haven't changed my view on feature freeze since #1410544: Consider possible ways to shorten code freeze [policy, no patch].

It's not been possible to come to a consensus on any of this between myself, Dries and Angie yet so I don't know what to say frankly. Just bumped an e-mail thread though for one last chance.

I wanted to follow-up on this as it has been a while. catch and I have been talking about this; we're strongly leaning towards catch's proposal of having reducing thresholds, and leaving core open for feature development as long we are under threshold. We're currently drafting up the details of how this would work, and expect to share the specifics by feature freeze date.

As a long-time subscriber to #1410544: Consider possible ways to shorten code freeze [policy, no patch] I'm interested in any developments there :)

However, I don't see how it's really related to the more immediate issues here...

Unless of course "reducing thresholds" actually means:

"First we raise them up for a short bit to give everyone a chance to get their features committed on a level playing ground. Then slowly lower them as time goes on."

Then perhaps it works.

Going to mark this fixed, we never really resolved the original issue here but Dries posted a blog post which covers features from now on at least:

http://buytaert.net/code-freeze-and-thresholds