- If someone finds a new issue/bug and wants to create a PR on it, he should first discover on the GitHub and Bug Tracking website whether a similar issue has already been raised. If not then he/she could proceed.
No, Trac is for issues. There are no issues on GitHub. They should check if there is an issue already on Trac, and if not create a ticket.
Updates from GitHub will trigger updates on the Trac side (using the improved read-only API available on djangoproject.com), ensuring clear, unidirectional synchronization.
A read-only API will not allow you to make updates, you would need to build a new API and think about authentication etc.
- Map Trac ticket flags to GitHub labels (e.g., “needs review,” “needs tests,” “needs documentation”) for easy filtering within GitHub.
This direction is Trac → GitHub which is against what you suggested before.
Error and Conflict Detection: Automatically detect merge conflicts and test errors, and notify contributors and maintainers when issues arise.
This feels like GitHub functionality and we shouldn’t add more notifications unnecessarily.
On key stakeholders, I don’t think you understand the Django team structure. Look into:
- Organization of the Django Project | Django documentation | Django
- Django Software Foundation | Django
Have you completed (had merged) any contributions to Django? If you want to automate any part of the contributing process, I would expect you to have done some contributions yourself in order to understand the process. Reading this proposal, I am not confident you have a strong understanding of the existing contributing processes.
Note that almost everyone in the project is a volunteer (Lily, Tim, Bhuvnesh). I think you would get better feedback by asking a specific question rather than wanting folks to review a 12 page proposal.