Why should it only be accesible for core developers? The strength of an opwn source communtiy is that everyone can pick up things to work on. Restricting access to core devs only means that only they can work on those issues. I'm afraid that'll cause an even slower solving time.

@wouterj let's talk about the details later. First we should decide if this a stupid idea or something that we could consider.

I find the idea of a issue reporter as a good one. It would simplify the process and make it easier for people to show their environment.
But the issue report should also take in account the PHP modules loaded/used. After all, the problem could also come because of a particular version of PHP or its plugins.

@thewholelifetolearn you are right: the report could also include the PHP.ini settings. But this is a detail to be discussed afterwards only if the idea is considered valid.

The second alternative seems great. But as it was said by @wouterj, it shouldn't be accessible only to core devs.

I agree too: the report should be accessible to everyone. Open source means opened to the world.
Maybe, it would be possible to use the "Gist" function of Github to report!
I don't know if it is possible to attach a zip file to issues in Github but it would be a possibility too.

I think "Alternative 1" is not very useful. The point of .phpt files is that a PHP developer can download them and launch them. They either fail or don't. If we create pseudo-tests that are in fact just descriptions with code, that's no more useful than current bug reports.

"Alternative 2" may be viable. However, I'm not sure if it helps. Currently, the hard and time-consuming task for someone fixing a bug is to find out how to reproduce it. This task doesn't necessarily become easier if a user submits the files that he thinks might be relevant.

I think submitting a symfony-standard fork is our equivalent to PHP's .phpt files. We can launch them, they fail or they don't. I also think creating a symfony-standard fork is one of the easiest ways to create a (useful) bug report. All developers are familiar with it, and they can simply copy the configuration of their project over to the test project instead of analyzing precisely which configuration values affect the bug and which don't.

Some thoughts:

• People picking files from their full project wouldn't help that much. There is a 95% change that it will be broken, because some class is missing. People should still create a new project (called "fork"), add the minimal code needed to get the error and then run the command.
• With that said, I'm not sure if running a command makes it easier/quicker than simply zipping it and posting it in GitHub.
• I would prefer to go with a common know file format, instead of reinventing our own format. For instance, we can use patch files.
• Commands like this should not be put in a framework bundle imo, since it is not related to the "framework feature". Maybe we have to include a task runner in the SE being able to do this. Related: symfony/symfony-standard#675
• @fabpot once started a blog post serie about packing the SE in one file. In the first post, he noted that this would solve exactly this problem. However, he never came further than post 2. Will that ever be finished?

I'd just like to pipe in with a little comment, that i think is the primary point that spawned these issues:

The problem is not contributing PRs or issues. The problem is the lack of response (in many cases, months or years) from anyone at all.

It is close to impossible for contributors to help out triaging issues as an outsider - how do we enable non team members help diagnose/tag/close/triage/fix issues? Not everyone who wants to help has the skill or ability to code.

I really like the idea of option 2. But as mentioned above, sometimes it's not Symfony itself that is causing the issue, it could be environmental.

I wonder if it'd be possible to use something like TravisCI to run tests against someone's fork/branch, so the testing environment is standard & known. It'd speed things up for narrowing down the issue.

Maybe a suggestion is to start using Gherkin to define tests, so they can be easily automated in some way?

Maybe a suggestion is to start using Gherkin to define tests, so they can be easily automated in some way?

👎 It would mean everyone needs to learn a complete new language and needs to know the available steps for Symfony.

I don't think these should be seen as tests. It should just be seen as packaging the local project of the reporter so we can look behind his shoulder, but without making secret information (including secret code) available on the web.

I'm in agreeance with @merk here. As a reasonably new Symfony user it is hard to know how to contribute. I have many years experience with PHP and am sure I could be useful somewhere, but its hard to know where to start.

Maybe we're approaching the problem from the wrong direction. Maybe the solution is not to find a new way to submit issues, but to improve the documentation and tooling for setting up a Symfony development environment, reproducing bugs, actually developing Symfony etc.

@webmozart this discussion tries to improve that.

@webmozart I think it's actually a bit of both, but yeah, I would definitely welcome that discussion.

/me goes to look at #11465

As @cjunge-work suggested, I was also wondering about travis or maybe a dedicated JoliCi instance managed by the symfony team (or stil some other simple testing environment managed with docker) to have a way to build environments easily and a share runnable test cases...

Anyway, at a first read, both of the proposed alternatives seems very legit to me. I believe we can also combine them and have the second alternative to produce a set of "standardized" declarations such as proposed in the alternative 1.

I agree with @webmozart, about the prospective,
do you think that creating a sort of mentoring group,
more knowledgeable person that pushes people to create a sf2 bugged branch,
and ping core developers, would help?

There's huge gap between core dev and sf2 experts, maybe this mentorship would also help to fill this gap...

I would agree with @webmozart that the we should provide the needed tooling to make it as easy as possible to provide a reproduceable branch. This should be sufficient for most cases to reproduce the issue and get into discussion.

From my experience in the last years I would also agree with @merk about the lack of responsiveness. If we would be able to provide better support with being more responsive the symfony users will be more satisfied and the issues won't clutter up.

As of today there are 645 issues open of which 121 issues did not get a single response. This is almost 20%. I have quit some experience with symfony now, but with many issues I am able to track the error down but for a fix I would need someone to discuss and to get quick feedback when creating a PR. We should discuss what possibilities we would have to improve this. Also contributing makes most fun if you see progress and if you get issues out of the ways quickly.

I would agree with @webmozart that the we should provide the needed tooling to make it as easy as possible to provide a reproduceable branch.

What about something along the lines of:

$ app/console bug:reproduce name-of-bug /path/to/some/directory
Installing symfony-standard at /path/to/some/directory...
Do you want to remember this path for future bug reports? Y/n
Updating app/config/config_dev.yml...
Creating branch issue-name-of-bug...
Do you want to copy your Composer settings? Y/n
Installing Composer dependencies...
Done.

You can use AcmeDemoBundle to reproduce your bug.
When you are finished, please run "app/console bug:report".

app/console bug:report would then upload the symfony-standard fork and return the link which can be included in the PR. Optionally we could also include the PR creation in that command, but I think that GitHub's UI is more intuitive in that regard (preview...).

I think the general idea is quit nice. A few things which we should consider:

• How would we handle the version of the SE? Based on the latest version or based
  on the version the user has in its repo. I think we should go with the current version
  since a bug might be fixed meanwhile.
• We could add the config settings and composer but do we really want to add that
  complexity to the standard process? Usually the bug should be reproducible without
  other bundles / dependencies. It will also be difficult if we go always for the latest Version
  parameters in the configuration might have changed etc.
• When reporting the bug I think we should just push the branch to the users remote which
  he has to specify when actually reporting the bug. And the command is just returning the
  link to the repo so the user can mention this url when pushing. An implementation needs to
  check if his repository is actually public. We might also think about another name since it is
  actually not reporting a bug. Maybe the report bug command is only available in a specific
  version of SE or based on a specific configuration settings to avoid any confusion when
  working in the actual application. In this case you might push your actual application.

And I think we should encourage users to just provide a link to the repo rather than creating a
PR with the issue, this would be a mess otherwise.

I personally like @weaverryan / knpuniversity's training videos. Maybe we could also provide
a screencast about how to easily reproduce a bug and open up an issue. This could include some
information around the process and might even replace the entire tooling discussed above. If we
educate people well they should easily be able to submit a branch with the issues.

👍

@weaverryan What do you think? Would you be interested in creating such screencast? Hopefully @Leannapelham want's to be part of this as well :)

@peterrehm we'd totally be up for that :).

I think we have some ideas, we just need to decide on what tooling (if any) we want to add. I like Javier's solution (2) and I think @webmozart's bug:reproduce is a more viable version of it (i.e. having them create a working project, not just upload a few files). It would still be some work for them to bring over offending configuration+files, but maybe over time the task could help bring over some additional pieces to make it less work.

So, should we try adding some tooling? Or should we just increase the documentation? There is also a middle option: add some tooling that doesn't do much more than just help walk you through the steps (and link you to docs for more information). Regardless of what we do, the goal would be to guide the user through each step of what they need to do and not leave them "dangling" at any point (i.e. not knowing what to do next).

Thanks!

I think it might be hard anyways to automate the process of getting a fork of SE for the user
with his settings. It might actually make more sense to improve documentation at first and educate
the users rather than automating actually a git clone. I think with this way we could tech again basics
and often if a user has no other dependencies, he might figure out, that the bug is not any more there, if its actually caused by any bundle.

If a screencast does not improve the issue reports we are getting we might consider further tooling. Anyway it will take time to get there but it will be a good reference to refer to when discussing on issues.

Any concrete feedback on tooling vs screencast/docs?

Not yet :). I'd like to see if someone can find some time to experiment with something scripted (also see #11660) and see if it can make it fore 2.6. Then, I'd love to make a quick screencast to show whatever the best solution is that we land on for 2.6.

For your information, Laravel has just released something like this. It's called Liferaft and works as follows:

# download a fresh new Laravel project to reproduce a bug
$ liferaft new bug_11289

# code, configure or do whatever you want

# send the reproducible fork of your app to reviewers
$ liferaft throw

# then, maintainers can download and reproduce the bug with this command
$ liferaft grab 11289

This demo (for liferaft) might be of interest too: https://laracasts.com/lessons/introducing-laravel-liferaft

This looks interesting considering homestead to make it also very easy for contributors to look at bugs. Such default dev / prod environments might make sense for Symfony as well.

We also need still to consider that we have to educate people to know what has to be done. Actually I think the advantage of such tooling is bigger for contributors than for the people submitting the issue.

What I don't like is that actual PR's are being sent to the Laravel Main repository since those are actually issues and not really code contributions. If we would consider such implementation I would send the PR to a separate repository and open up an issue on the main repository. If we use a standard issue format on the top we can still fetch the corresponding PR without any big troubles.

filtering by label should work tho. github has made that pretty easy now. not sure a seperate repo is needed.

I didn't make my final thought on that one. A label might be a solution, in any case "cluttering" of the PR's should be avoided. Another option would be refer just to the remote branch of the submitter with the risk of loosing the data.