Ya, I see! sorry for that and thank you for catching this.
I misunderstood it due to reading the previous context
I have corrected it:
Pull Request (Patch) Management: Django uses a dual-system workflow of GitHub and Trac.
Trac (code.djangoproject.com) tracks issues, bugs and discussions and GitHub (GitHub - django/django: The Web framework for perfectionists with deadlines.) handles code changes via standard pull requests. Contributors have to refer to Trac ticket numbers in their GitHub PRs (e.g., Refs #1111) to maintain traceability." Each open ticket undergoes a rigorous review process…
Thank you very much @boxed for saving me from this blunder.
I request you to please check the revised draft once again when you have free time, please.
On labeling stale PRs, instead I think PRs which have received a review and their related ticket is updated so that it is no longer in the review queue could get a message of “are you still planning on working on this?” if there is no further activity after 3 months. Then after 1 more month of that PR not being worked on, the PR could be closed. This is something that is done occasionally and manually. Even this needs thought as to whether a bot doing this instead of a human is “wanted” or just rude
On automated releases, this doesn’t really show much understanding of the current process unfortunately. Instead, I would recommend you look into Natalia’s checklist generator which aims to create checklists of tasks per release: GitHub - nessita/checklist-generator. There is a goal to slowly merge this (with tests) into djangoproject.com and to build this out further. I think if you can run this locally and play around and show that you understand this project, that would be a good first step in this “area”
One area I would love to see more on is around reviewing PRs or giving more feedback to contributors early. Things like: checking test the coverage of new/updated code, if code has changed there is at least some tests written, versionchanged/versionadded notes checked, release notes checked, line length of the docs checked. I would love to see that you have gone through PRs that have been reviewed and our contribution guidelines to show that you have a strong knowledge of Django’s specific processes and where we can make improvements
It’s also worth you showing who the key stakeholders are and how you are going to work with them and bring them onboard to the changes. Django is a community run project and if there are members of the community strongly against these changes, nothing will happen.
About releases understanding: I knew its vagueness and was refining it behind the scenes. Now I have updated it and also other sections considering your suggestions.
On sync: Designate GitHub as the source of truth for code changes, testing, and documentation and Trac for issue tracking and historical context
I update the PR staling in three phases
I have setup the Nessita’s checklist generator as per your suggestion, I got
ModuleNotFoundError: No module named 'django_better_admin_arrayfield'
It was neither listed in requirements.txt and requirements.in
I solve it, take many ideas from it but yet hacking around the admin panel.
Ask for key stakeholders: I have an update about the stakeholder section as per your guide
Potential Mentor: The mentioned mentor @Lily-Foote is not responding, I also tried to contact her through LinkedIn, but she hasn’t reply yet, I’m waiting for her feedback, could you help me in that?
I read again official docs and my research to update my release automation and PR monitoring considering and approaches
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:
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.
Thanks once again for your precious inputs, I understand the point
On PR statement: I accept my mistake, I didn’t notice my typo. And I strongly disagree with my statement.
On Key stakeholders: Ya! I took it in the wrong way (first time) But I got it with your reference. I will mention the team!
On Sync: Thanks for making suggestion on it, I was already confused with it and going to create a post to seekh help. Does it need in my proposal to update or create a new one and also I’m confused with its flow direction
When I was working on a ticket I got two reviewers in three days and after discussion and flagging as duplicate my ticket URL got removed, but can I ask how that reviewer reach to my ticket, does they do custom query or get any notification or any dashboard metrics. It’s related to my proposal.
My Any Contribution: I worked on #36244 (not merged) I was doing another one but it found to be duplicate, and on third, I’m going to (searching for a ticket, could you refer any🙏?) I realise practical experience is crucial
Could you give inputs on the release process (if you have time): does only requirement is merging checklist generator?
Thanks for clearing my anxiousness on Mentor’s feedback, I was requesting so, as per described on Django GSoc page to take inputs from others.
I just started working on it this weekend. I thought I’d do it faster, but I was short on time. I have no problem with you taking it.
I’m sharing my comments and what I was able to do so far.
Natalia’s feedback
From my point of view, the next step is to “play” with my PR and Simon’s project, and think about how we can improve the Django setup. One important thing is that we won’t be adding any new dependencies to Django for development, so for now, although one could use playright unofficially, the “official” solution wouldn’t be possible (at least not without a forum post for the community to give their opinion).
What I’ve done
# First fork django
# Move to issue branch
gh repo clone marcorichetta/django
gh pr checkout 18211
# Merge with main to update the branch
git merge main
# Create virtualenv and follow tests/README.rst
uv venv --python 3.12 # pyproject requirement
source .venv/bin/activate
cd tests
uv pip install -e ..
uv pip install -r requirements/py3.txt # Comment pylibmc until I can build it
# Run all tests
./runtests.py
I will work accordingly…
But sorry to ask… could you tell me about the screenshots context (your perspective till now)? did you autogenerate these images → marcorichetta/django/tree/master/docs/ref/contrib/admin/_images, does this screenshot will show on https://docs.djangoproject.com/en/dev/ref/contrib/admin/ and state about /news
I’m a beginner in Django contribution not a very pro, your feedbacks are very helpful
@marcorichetta Hi! Since you’ve already started working on this ticket, and unless you’re certain you can’t continue, I think it makes sense for you to keep going. You’ve already built context and invested time in research and progress.
Hello @nessita
Sorry to message you here
I hope you got context about me: alike beginner contributor
My GSoC project idea is quite uncertain
involve working with the Fellows to determine which of their tasks and the community’s tasks are the best candidates for automation.
The description has a point for automate releases. I did not find much. Senior Sarah suggested looking for your GitHub - nessita/checklist-generator with goal of slowly merge this (with tests) into djangoproject.com
I am hacking around it, Initially I get some errors but now it’s going decently
If you don’t mind and have some time, would you like to suggest some (e.g., approach to merge)
Adya here again.
But I got it with your reference. I will mention the team!
