Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Initial Website working group proposal #10

Open
wants to merge 30 commits into
base: main
Choose a base branch
from
Open

Initial Website working group proposal #10

Changes from 9 commits
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
812d3a9
initial proposal for Website Working Group
ronnzw Jan 12, 2024
5049cd5
Adding Liaison
ronnzw Jan 12, 2024
15673f8
typo fix
ronnzw Jan 12, 2024
5e5bea1
removing Jacob
ronnzw Jan 22, 2024
02ebd0c
Removing Liaison
ronnzw Jan 22, 2024
7948a8d
review updates
ronnzw Jan 22, 2024
3c057b0
Update active/website.md
ronnzw Jan 23, 2024
b83468a
wg description
ronnzw Jan 23, 2024
4cd3a46
update comms
ronnzw Jan 23, 2024
d17ba20
Update delegated responsibilities
ronnzw Jan 29, 2024
9bb86a7
Update members' responsibilities
ronnzw Jan 29, 2024
b67af2d
Update active/website.md
ronnzw Jan 29, 2024
d1a1def
Update delegated responsibilities
ronnzw Jan 31, 2024
8bb169d
updated voting and term
ronnzw Jan 31, 2024
e250616
Update remove coc statement.
ronnzw Jan 31, 2024
0f205f7
Update active/website.md
ronnzw Apr 15, 2024
7f6cdb5
Update website.md
ronnzw Aug 20, 2024
06a804c
Update active/website.md
ronnzw Aug 22, 2024
85a030a
Update active/website.md
ronnzw Nov 19, 2024
9c5931e
Update active/website.md
ronnzw Nov 19, 2024
957a6a1
Update active/website.md
ronnzw Nov 19, 2024
5c64eb1
Update active/website.md
ronnzw Nov 19, 2024
f1343ee
Update active/website.md
ronnzw Nov 19, 2024
b3357d2
Update active/website.md
ronnzw Nov 19, 2024
b0fde57
Update active/website.md
ronnzw Nov 19, 2024
ac38a56
Update active/website.md
ronnzw Nov 19, 2024
98d65ef
Update active/website.md
ronnzw Nov 19, 2024
f098802
Update website.md
ronnzw Nov 19, 2024
f6c3d93
Update website.md
ronnzw Nov 19, 2024
ed29e9e
Update active/website.md
thibaudcolas Nov 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions active/website.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
# Website Working Group

## Scope of responsibilities

This is a replacement of the current maintainer team @django/djangoproject-com-maintainters. The team will own maintenance of the website codebase, and liaise with the @django/ops-team for production infrastructure considerations.

The duties of the working group are:
thibaudcolas marked this conversation as resolved.
Show resolved Hide resolved
- Introduce new features on the website
- Maintain and monitor the website
- Ensure that information on the website is accurate
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Help to make the website accessible to all

ronnzw marked this conversation as resolved.
Show resolved Hide resolved

### Delegated responsibilities:
Copy link
Member

@thibaudcolas thibaudcolas Jan 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see two additions:

  • Who has the right in the group to merge pull requests? Is it "chair / co-chair / board liaison", or "everyone" or "no one"?
  • Who has the right to publish new content on the site?

Edit: discussed on 2024-09-26 w/ 8 provisional WG members, see last comment.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Who has the right in the group to merge pull requests? Is it "chair / co-chair / board liaison", or "everyone" or "no one"?

I don't think "everyone" is a particularly safe option. If we want to make it "everyone", the vetting process of adding someone as a member need to be more precise to ensure that nothing bad gets merged. Also, there needs to be a process to re-evaluate permissions if anyone feels like they need to leave the WG.

But I feel like the django-com-maintainers team who already have permission and are actively maintaining the website currently should still have the permission (unless they themselves don't want the permissions anymore).

So here are few thoughts of mine:

  • We can either make the process of adding someone to the WG more strict and always have a limited number of folks as members. From a security point-of-view, I am not a fan of too many people having merge access.
  • The other option that I can think of is letting "everyone" have merge access, but making the branch protection rules stronger. For example, at least 2 members need to approve the PR fo it to be merged, and only the chair/co-chair/board liaison may be able to override it, in case of any emergency requirement.
  • The third option I can think of is segregating members into Maintainers and Members, where Maintainers have merge access, but Members can triage and stuff.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Who has the right to publish new content on the site?

Ideally, I would say there should be an editorial WG team who handles publishing of content.
@sabderemane mentioned to me that there are multiple different teams who have the access and need the access to publish new content. From a strictly security perspective, I like the idea of Website WG not having permission to edit content (unless there are crossovers with other teams of course). Given we have a board liaison who I think already have permission to publish content being part of the Board, that should suffice in case there is a need to intervene.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The third option I can think of is segregating members into Maintainers and Members, where Maintainers have merge access, but Members can triage and stuff.

IMO, the third option seems to be a good one, at least maintainers is not everyone and we don't have to restrict the access to be part of the working group. We can based the list on the current members who are part of the django-com-maintainers and add more members in the future if needed. We will need to define how to add a maintainer to the Maintainer team but I think it's not a prerequisite to kickstart this WG.

Copy link
Member

@sabderemane sabderemane Aug 21, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of Website WG not having permission to edit content (unless there are crossovers with other teams of course)

I agree on this, as it's replacement of the initial maintainers team, they actually don't have the write to publish content, only edit eventually content which is hardcoded in html.
I find quite interesting the idea of the editorial WG team, I'm not sure as a working group but this is a separate topic I will see as board member.

Given we have a board liaison who I think already have permission to publish content being part of the Board, that should suffice in case there is a need to intervene.

Yes 💯

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me too! Agree it’s not a blocker to starting the WG since we already have a maintainers team currently.

Copy link
Member

@thibaudcolas thibaudcolas Sep 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Permissions / access to resources:

  • Website deployment: ping via @django/ops-team on the pull request for deployment.
  • Merging: initial onboarding phase where only Chair and Co-Chair have permissions to merge. After onboarding of 3-6 months, other group members who have proven their expertise will be granted merge permissions.

Ops team will retain access, and in case there are site infrastructure issues, would be able to restrict permissions.

Other resources that are relevant but could be done ad-hoc:

  • Stripe
  • Sentry
  • reCAPTCHA
  • (Trac)
  • Transifex

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sentry access to the (majority of) the group would be a great benefit. Maybe some of the group, chair/co-chair, having slightly different permission and having a sentry team defined.

- Chair, Co-chair and Board Liaison can make final decision of sections of the website that might not conform with DSF's CoC.
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Members can work on bugs
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Members can tag,label and respond to issues.
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Member can maintain and monitor the website including updating versions
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Mentor new contributors to the website
- Chair, Co-Chair and Board Liaison can sign off on new features
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Chair, Co-Chair and Board Liaison can sign off on new features
- Chair, Co-Chair and Board Liaison sign off on new features


## Initial membership

- Chair: TBA
- Co-Chair: TBA
- Board Liaison (must be an active Board member; may be the same as Chair/Co-Chair): TBA
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs filling in ahead of a board review.

Copy link
Member

@sabderemane sabderemane Jan 31, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy to be Co-chair if it's ok for everyone

- Other members:
- Sarah Abderemane
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Eric Sherman
- Mark Walker
- Jason Judkins
- Paolo Melchiorre
- Sanyam Khurana
- Tobias McNulty
- Ron Maravanyika
ronnzw marked this conversation as resolved.
Show resolved Hide resolved



## Future membership
ronnzw marked this conversation as resolved.
Show resolved Hide resolved

### Who is eligible to join? Any volunteer, or are there specific requirements?

Members must have interest in Django and should be able to work with Django. Most importantly members must be willing to adhere to Django's [Code of Conduct](https://www.djangoproject.com/conduct/) . Members must be well versed with the process of contributing to **djangoproject.com** or at least willing to be guide. We welcome all experience levels, we also welcome first time contributors.
ronnzw marked this conversation as resolved.
Show resolved Hide resolved

### How do people who want to join sign up / volunteer / express interest?
Individuals can express interest by emailing to the working group mailing list at `[email protected]`
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
ronnzw marked this conversation as resolved.
Show resolved Hide resolved

### How will decisions on adding/removing members be handled?
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
Direct membership: new members may self-nominate; the WG will vote (50%+1) to approve/deny new members; the WG will directly vote on new Chair/Co-Chairs.
ronnzw marked this conversation as resolved.
Show resolved Hide resolved

Members join the group for a 2 year term. At the end of this term, they need to opt into staying involved to keep being
a member of the group.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting idea, I hadn't seen it before! What was the reasoning here? Is this something that maybe is a good enough idea we should adopt more broadly?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As time goes on people get new commitments and it's not always easy to give feedback on their intentions, especially for people that contribute on multiple projects. Not sure if it applies to all working groups.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we have a shorter term? 2 years feels like a long time to me, if people don’t want to be involved anymore it’d be better for them to be able to head off after 6-12 months.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i feel two years is ample time for this type of groups, maybe we can add that individuals can leave at anytime. The idea here is not to keep individuals that aren't interested in the group anymore but haven't found time to notify the team. This is not to stop members from leaving the group.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think we could have shorter terms.



## Budget
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
No allocated budget
ronnzw marked this conversation as resolved.
Show resolved Hide resolved

## Comms
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
- Private channel in the DSF slack
thibaudcolas marked this conversation as resolved.
Show resolved Hide resolved
- A mailing list that we'll create, `[email protected]`
ronnzw marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- A mailing list that we'll create, `[email protected]`
- A Django forum sub-section "Website" of Django Internals

We migrated developer and user mailing list to the Django Forum, so let's try to use the same platform for asynchronous communication (the preferred way as we can be in different time zones), but having the private Slack or Discord channel for synchronous communications in case of emergency, meetings or for faster interaction.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds great, particularly considering that section already exists! Website.


## Reporting
We'll email a written report to the board every quarter.
ronnzw marked this conversation as resolved.
Show resolved Hide resolved