👍 I would really like to see the issue list shrink. It's nice to get new features, but if you can't upgrade to that version because of blocking issues that aren't looked after, it's pointless.

I'd like to add that critical bundles shipped with the standard edition or used in most projects, like FrameworkExtraBundle, DoctrineBundle and AsseticBundle need significant attention with their tickets as well.

Sometimes you might not receive a response at all for legitimate issues because there is no active maintainer. I'd like to see a push for more accountability of maintainers of bundles. I'm trying to push for this in the FriendsOfSymfony organisation so we can better deal with bugs and support requests.

Wouter, thanks for opening this issue. Here are my thoughts:

• I agree with improving the feedback time and response time for reported issues and committed PR.
• I don't agree with changing the release process, because that would result in endless delays, as it happens with most software projects.
• I agree with giving more care to the bug issues.
• I agree with the "no-new-features release". This is something that I've mulled over in the past and I see no strong reasons for not trying it at least for one release.

I know that is obvious, but the solution would be to have more people on board for Symfony development. Some projects are testing new ways to promote commits and PR from companies, such as this proposal by Drupal to give credit to companies that contribute to Open Source.

Thanks for bringing these "problems" to the table.

If you have a closer look, we've been in feature-freeze since 2.3. Recent versions did not get any new major features (at least on my side, I have not worked on any feature that took me a long period of time since 2.3.) There are several reasons:

• There aren't that many new features to add to the core components (most of the work can happen in bundles);
• We (I) spend most of my time merging pull requests about small changes or bug fixes (which is a great thing);
• We cannot change things too much because of our BC promise.

We do have a lot of opened tickets, but you also should mention the large number of tickets/PRs that are closed every day, it would give a slightly different perspective on the current situation.

IMHO, we really need more contributors willing to review patches, fix bugs, and more...

Regarding the release process, I think it has a positive impact on the problems you mention as it gives incentives for some contributors to actually push changes, merges contributions before feature freeze twice a year. I know that I finished some PRs because we were about to enter a feature freeze.

I'm open to any suggestions to solve some of the problems you mention, but at the end of the day, the limit is the amount of time we (collectively) spend on fixing bugs, reviewing patches, understanding problems, finding good solutions, ...

Of course there are new features, otherwise the "New in Symfony 2.x" blogposts made no sense. New validation API, the ExpressionLanguage component, new commands (translation:debug, twig:lint, yaml:lint, ...), Form Debugging, etc. But my issue isn't really about that.

My issue is more about the fact that old issues and PRs aren't cleant up. Some tickets are there for years without any comment or action. Maybe half of them are already fixed, but nobody ever looked at them to notice that. That's why I suggest to stop doing what we do now and focus on cleaning up those things first (since it turns out we can't do both things in one go).

And the other point made in my issue is that we just need to give a second more love to authors of PRs and issues. Just saying "Thank you! Great catch! Awesome you noticed that one!" when labeling it can already make a huge difference.

With the DX initiative, you see that people quickly response on it and by that, people are very happy to open new DX issues. If we manage to do the same thing for the "normal" (as if DX isn't normal) PRs and issues, I'm sure we get more things done with more people which contribute on a weekly basis.

Labelling is done by the gh tool and I can manage to tag 100 issues in less than 3 minutes, meaning that I don't actually read everything, as most of the time, just the title is enough to tag an issue.

If we stop doing what we do now, we will accumulate a bunch of newer issues and PRs. The problem is the number of people involved in the core team.

There is a big difference (in time) between "opening a DX issue" and "fixing an issue", "reviewing a patch", ...

Again, we do have old issues that need love, but I don't see how I can fix this issue alone.

Again, we do have old issues that need love, but I don't see how I can fix this issue alone.

Please note that the last thing I want to do here is to blame you for anything you do for this community. I've tried to always use "we" instead of "you" in my issue. It's "we" that should fix it, we as the complete Community.

I didn't knew the GH tool automatically labelled the issues. Now I can understand more why those component labels gets added without a label. But labelling it with a component is not enough, someone has to look at it (not even with the intention to fix it, just with the intention to inspect the problem).

The difference between "responding to a DX issue" and "responding to an issue" is not that big and you can clearly see a response difference between DX issues and normal issues (all DX of the last 19 days have at least 1 comment).

I was around in the symfony community for quite some time in the past (before 2.3 was official). It was 6 months before my ticket about the licensing issue to be noticed (the apache licensed bundles). It took bugging Crell to get that issue brought to the table.

I've spent a lot of time triaging tickets for symfony and related bundles (both included in symfony standard
and ones like FOSUserBundle), but in most or many cases there was no response.

The whole process of trying to work in the ecosystem and get noticed caused me to become very frustrated. I ended up leaving for awhile and playing with rails.

I was sorta hoping that my efforts both on issue trackers and IRC would be noticed and that folks
might have realized by now (back then) that i was pretty committed to symfony and ask if i wanted to help out in a more direct way (a mostly non coding way).

@fabpot : none of us expect you to do everything alone. We expect you to enable us to help

I think that there are more than enough people willing to help out with what ever they can (myself included). Especially if you take a look at IRC in # symfony.

Are there any plans in future to move issues to their respective repositories and release components independently?

@yosmanyga you can already use Symfony Components independently from the full-stack framework. Here you have the list of components, which are fully documented and ready to help you with your applications.

Regarding the separation of issues, in my opinion the current model is much better, because we centralize all the issues in a single place and therefore it's harder to miss any reported issue.

I do agree with @javiereguiluz regarding centralizing the issues/pr in 1 repository. However, searching is pretty dramatic because it's a never ending list.. However, it's easier for people to create issues in symfony/symfony rather than find out where the problem might be and post it in there.

I would appreciate a read-only system in components so that you can read through all the issues related to that component/bundle but placed in symfony/symfony. I think this is not possible in github, but I could be wrong. Earlier I was searching for an issue I once found regarding the Template Annotation and setting cookies.. It was impossible to find and I couldn't trace it back.

@iltar you can filter by component using the labels

But it won't search in the subtree (?) repos for tickets as far as I know

I was responding to "However, searching is pretty dramatic because it's a never ending list..", since you can do things like: getId label:security

But let's not go off-topic...

@javiereguiluz I was referring to the releases, not tied to a central versioning, just using semantic versioning, e.g.: component xx v2.7.5, component yy v2.8.1.

Regarding the centralized issues, do you imagine the same model for all the linux commands? IMHO, all issues reported in the same place overwhelm the community and tie up the components to the sf framework.

I agree that we just need more people that feel empowered. If we had even 10 more WouterJ's, Stof's or @jakzal's actively commenting on PR's, reading, understanding and testing bug issues to see if they are (in)valid and helping think critically on difficult feature requests, then we'd be in great shape. @wouterj mentioned that the DX issues all have at least comment, and it's because a few of us have automatically been following up on those without being asked.

So to me, the solution is just answering this question: How can we empower more auto-triagers (i.e. people that just see an issue and jump on it)? Can we involve companies? Would giving contributors of this type more credit help? Would some simple blog posts and PR to "invite" people do it?

And I also agree with the issues Wouter is bringing up - it's really unfortunate to leave an issue sitting with no response. We need to seek the man-power to avoid this. I'm really lucky to have an amazing team of these "auto-triagers" for the docs :).

I'd be willing to commit a bit of time to triaging, and I'm sure there are a few more out there as well. Not sure how to manage that, but more eyes = more bugs looked at, even if it's to close them.

Going through the issues starting from the last page is what I'm doing occasionally. It's not easy, last time I did it, it took me over a month ;)

The hard bit is trying to confirm whether an issue is still an issue ;) it takes a while to understand and reproduce a problem.

I started labelling issues to reproduce as Unconfirmed, so people who'd like to help like @cjunge-work could find them quicker. I'm pretty sure that after some time of doing this people will start reporting bugs with a link to SE with a reproduced problem (some already do this). Might be worth mentioning something about it in the docs (if it's not there yet).

It's easier if people can supply a patch/PR that you can run on the default installation to reproduce... You could even automate that by checking out a fork and run a "unit-test" or functional test for it.

@iltar agreed. However, not everyone can write unit or functional tests. A fork with code reproducing a problematic scenario proved to be sufficient in most of cases.

@iltar that discussion should be done in #11494

Closing, the new 500 100 challenge kind of fixed this issue and I made my point :)