Opened 9 years ago
Closed 8 years ago
#26359 closed Cleanup/optimization (wontfix)
explain dual ticket tracking system
Reported by: | Becka R. | Owned by: | Philip James |
---|---|---|---|
Component: | Documentation | Version: | 1.9 |
Severity: | Normal | Keywords: | |
Cc: | kai@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
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!
Change History (12)
comment:1 by , 9 years ago
Component: | Uncategorized → Documentation |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 9 years ago
Type: | Uncategorized → Cleanup/optimization |
---|
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.
comment:3 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
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.
comment:4 by , 9 years ago
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/.
comment:5 by , 9 years ago
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.
comment:6 by , 9 years ago
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/
comment:7 by , 9 years ago
Cc: | added |
---|---|
Owner: | removed |
Status: | assigned → new |
Maybe someone has a better idea to solve this?
comment:8 by , 9 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:9 by , 9 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:10 by , 8 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:11 by , 8 years ago
Has patch: | set |
---|
Pull request here: https://github.com/django/django/pull/6692
comment:12 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
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.
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.