explain dual ticket tracking system

[Becka R.]

The contribution documents at ​https://docs.djangoproject.com/en/1.9/internals/contributing/ link to the Trac system for creating tickets.

I was confused when the first ticket I made was a duplicate of an issue on Github.

It would be very helpful to explain that there are also tickets on GH and why (legacy? I'm new here) and how to check for dupes. Is there a preference for what gets reported where? Please explain this to make it more n00b friendly. Thanks!

[Russell Keith-Magee]

There aren't any *tickets* on GitHub - we've disabled the Issues feature on our Github account. However, we do accept Pull Requests on GitHub, which have a number that is very similar to a ticket.

So, if you're reporting a problem, you need to use Trac; when you submit a pull request, that PR will be given a number, and that number should reference the Trac issue number.

I know this is a bit confusing, so improved documentation is definitely a good idea. The source of the problem is that GitHub's ticket system isn't practical for a large project like Django, and we had a legacy of 20000 tickets in Trac (many of which had a significant history) that couldn't be imported into GitHub when we moved our repository there.

[Tim Graham]

I guess this is about duplicating the "Read this first" information from https://code.djangoproject.com/newticket:

Please don't report security issues here! Contact security@… instead.
Report bugs and suggest features in Django itself (or its documentation) using this ticket tracker.
Don't use the ticket system for help with support questions. check the FAQ for common issues.
Use Transifex for bug reports on translations.
Report issues with our web site (www.djangoproject.com) in its GitHub issue tracker.
Report issues with our bug tracker (code.djangoproject.com) in its GitHub issue tracker.

It would be nice if we can solve the issue without duplicating this information such that we have to maintain it in multiple places.

[Kai Feldhoff]

What a about adding a paragraph about the role of GitHub at ​https://docs.djangoproject.com/en/1.9/internals/contributing/triaging-tickets/#triage-workflow

We could cover the following aspects:

• forking django in GitHub
• the git part of work at home
• create pull request in GitHub
• working with failing test
• working with merge-conflicts
• rebasing

I know that all this already exists in the docs, but my first experience was, that the information about the complete GitHub-workflow is spread over different sections. So in most cases a short description with a link to a more spectific page should be sufficient. But I have to go through this in detail.

[Tim Graham]

I don't see how those ideas address this particular ticket. Most of the steps you outlined above are addressed in ​https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/working-with-git/.

[Kai Feldhoff]

OK, I read again and see. My first impression was not representative here. Really everything is covered in ​https://docs.djangoproject.com/en/1.9/internals/contributing/. It's quite a lot to read for new contributors like me, but it is needed to get a full overview of the process.

I see a minor issue that the section ​https://docs.djangoproject.com/en/1.9/internals/contributing/writing-code/working-with-git/ is also important when triaging tickets (code reviewing/testing), writing documentation and committing code. Maybe it is possible to move this section more up in the hierarchy, but I seen no good place to add it elsewhere. Or maybe in ​https://docs.djangoproject.com/en/1.9/internals/contributing/new-contributors/#first-steps?

When the role of GitHub in the ticket process is clearly pointed out, then I consider this issue to be solved.

[Kai Feldhoff]

I additionally noticed, that the Trac-Wiki https://code.djangoproject.com/wiki also has a bold note for the use of GitHub. It would be perfect if this kind of highlighting also occurs in the docs.

I favor ​https://docs.djangoproject.com/en/1.9/internals/contributing/new-contributors/#first-steps. We could add a second point in the first list like this:

Learn how to work with Git and GitHub
No matter if code or documentation, everything finds its way into Django through GitHub. If you are not familiar with Git start here: ​https://docs.djangoproject.com/en/1.9/internals/contributing/writing-code/working-with-git/

[Kai Feldhoff]

Maybe someone has a better idea to solve this?

[Philip James]

Pull request here: ​https://github.com/django/django/pull/6692

[Tim Graham]

As discussed on the PR, it's not clear that adding more information will help, given the info is already present on the new ticket page.