2 Oct 2025
Attendees: Jason, Sanyam, Baptise, Adam, Tobias, Storm, Ülgen, Saptak, Alex
Apologies: Sarah
Agenda
- Review Action Items
- Review triage documentation together (we expect everyone present to be familiar with the document at this point)
- Website Redesign thread on forum
- Review questions
- Any other business?
Action from last meeting
- Everyone: review the security document PR
- And its sibling: Update security.txt PR - Everyone: Review and comment Website Triage (draft)
- Sarah: check access for the website with the ops team
- Baptiste: see about access to matrix with Fastly (for website stats) and can we ask for more access
- Sarah: Define what actually means inactive
- Saptak, Alex, Sanyam & Ulgen: review the docker setup for the website
- https://github.com/django/djangoproject.com/pull/2207 - Saptak: Look into improving the contribution guidelines
-
Sarah: review PRs to merge - Sarah: contact Fundraising WG for the Baptiste’s improvements for flatpages when it’s deployed
- Baptiste: did you manage to deploy it?
Actions for next meeting
- Everyone: review the security document PR
- And its sibling: Update security.txt PR - Saptak: Address comments in the Triage document and finalize it. Check with Sarah where it lives.
- Sarah: check access for the website with the ops team
- Baptiste: see about access to matrix with Fastly (for website stats) and can we ask for more access
- Sarah: Define what actually means inactive
- Saptak, Alex, Sanyam & Ulgen: review the docker setup for the website
- We still have one PR from Tobias, Saptak will review it - Saptak: Look into improving the contribution guidelines
- Saptak, Sarah: Baptiste’s improvements for flatpages when it’s deployed https://github.com/django/djangoproject.com/pull/2144
- Look more into site-breaking monitoring and bug reporting, Maybe cleanup sentry?
- Baptiste: Bring up adding more Web people to Sentry
- Saptak: Decision making docs
- Everyone: https://github.com/django/dsf-working-groups/pull/55
Questions
- How to make decisions and resolve conflicts?
- Majority? - Alex, Adam
- Strict/loose consensus? - Ulgen
- Quorum quora?
- How many people should be there in the meeting for a decision
- Maybe if we can’t reach consensus, we decide to majority vote - Storm - Decisions regarding test coverage
- Enforced test coverage via CI by tobiasmcnulty · Pull Request #2201 · django/djangoproject.com · GitHub
- Any objections to codecov? -
Where should we keep all our WG rules/documentation? Google docs? GitHub wiki?
Notes
- Review Action Items
- Everyone: review the security document PR and its sibling: Update security.txt PR
- Storm approved, one comment about the github-only reporting process requiring a GitHub account. Acceptable?
- Everyone: Review and comment Website Triage (draft)
- Review as next agenda item
- Sarah: check access for the website with the ops team
- Unsure if this has happened
- Baptiste: see about access to matrix with Fastly (for website stats) and can we ask for more access
- No updates
- Sarah: Define what actually means inactive
- No updates
- Saptak, Alex, Sanyam & Ulgen: review the docker setup for the website
- Did see some activity
- Some small issues left
- Tobias has related PRs with open questions
- Where the migrate command should run
- Questions to run tests
- Move to pyproject.toml
- Things seem to be moving along
- Saptak: Look into improving the contribution guidelines
- Have not done that, moving this to next time
- Sarah: review PRs to merge
- Done
- Sarah: contact Fundraising WG for the Baptiste’s improvements for flatpages when it’s deployed
- Was this deployed?
- https://github.com/django/djangoproject.com/pull/2144
- Two comments
- One about using a different package
- Not sure about consensus
- Baptiste keen to deploy to preview server to give people opportunity to test, but prefer not to if this is not the way we want to proceed
- PR itself is not that big, because all the code is in an external package
- Everyone: review the security document PR and its sibling: Update security.txt PR
- Review triage documentation together
- Lots of comments!
- Where is this document going to live? In Google Docs or a GitHub Wiki?
- GitHub wiki option is getting many +1 from team members present
- Finalizing this document should still happen in docs
- GitHub wiki does not appear to support pull requests, might make reviewing changes harder
- Response time section, lets not do this
- Seems like an unreasonable expectation
- Get rid of this
- Who is going to address the comments?
- Issue templates
- Things like: Feature request, bug report etc
- Lets suggest some issue types and discuss this with the working group
- Site breaking bugs / critical issues
- How do we define this?
- Do we have things like Sentry set up to keep track of server errors? Do we have monitoring?
- We do have Sentry set up, bit reluctant to give out access because it might contain sensitive data
- We can give access but it is quite messy with lot of messages (from documentation building, especially for the translation component)
- Potential solution: configure Sentry to ignore these errors
- Or try building the docs locally and figure them out
- Have to do some housekeeping
- Historically, we haven’t used Sentry for pro-actively fixing issues, we wait until someone reports it
- We should be using Sentry more
- Action for Baptiste: bring up adding more people to Sentry at next operations team meeting
- https://django-dsf.slack.com/archives/C06U18AB7EY we have a slack channel where a bot posts when the site goes down, based on Grafana monitoring
- People interested can join this Slack channel
- The bot is quite accurate, it rarely gives false information about uptime
- We also have https://status.djangoproject.com/ - looks like this is hosted externally
- Document mentions issue triage meeting
- What would this look like in practice?
- Video meeting or asynchronously over Slack?
- Idea: triaging duty that rotates
- Policy for closing abandoned PRs
- Closing a PR with a message after some amount of time without a response from the author
- Next steps: apply improvements to document and resolve comments, get back to this next time
- Website Redesign thread on forum
- Django Homepage Redesign
- djangoproject.com - User Research Report - v1.0.pdf
- The forum thread is about the homepage and is quite long and holds opinions
- Will the website get redesigned?
- Yes, this is what the website working group
- There are some steps before we can start writing code
- Decisions about marketing: how do we market Django
- User research, already (partially) done by tab20
- Navigation structure
- Content structure
- There is some discussion happening about marketing
- Nice summary of the above by Thibaud: https://forum.djangoproject.com/t/want-to-work-on-a-homepage-site-redesign/42909/15
- This is the process we are leaning towards instead of doing incremental improvements
- Figure out how to collaborate with the Adam that started the forum thread
- We do plan to be more transparent about the website redesign and the things that are happening behind the scenes, this is with Thibaud and [didn’t catch the name]
- Questions
- Will we be relying on volunteer resources or will we be using professional services?
- Under discussion with the board, no clear answer
- If we change the foundation of the site, many issues and PRs will get stale or obsolete
- Aggressively triage and close open issues/PRs before the redesign starts.
- We also still maintain the current website until the new website launches
- Are we going to apply (parts of) the redesign Adam made into the current website?
- Not drastic design changes that conflict with the current design
- But updated content and some new blocks might be accepted
- Will we be relying on volunteer resources or will we be using professional services?
- How to make decisions and resolve conflicts?
- Consensus vs majority voting
- Like the simplicity of majority voting
- On the other hand, experience has learned that we are quite hesitant to make changes to things that are already in place. If we go with majority voting we will likely be making more conservative decisions.
- [formulated and added later to support the above point: While we do not have an official authority hierarchy, majority voting may - at times - result in others following the opinion of someone they perceive as authoritative. Resulting in the ‘argument from authority’ fallacy, instead of compromising and making a decision everyone can be happy with]
- Census voting is likely be a slower decision making process
- Voting quorum? When is a decision valid? (because enough people have given their vote)
- Saptak to write a document to describe our decision making process
- Decisions regarding test coverage
- https://github.com/django/djangoproject.com/pull/2201/files
- Any objections to codecov?
- We are at time
- Last question, new member?
- Discuss on Slack and maybe at next meeting
- Thanks all!