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 18 commits into
base: main
Choose a base branch
from
Open

Initial Website working group proposal #10

Changes from all commits
Commits
Show all changes
18 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
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
61 changes: 61 additions & 0 deletions active/website.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# 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
- Help to make the website accessible to all

ronnzw marked this conversation as resolved.
Show resolved Hide resolved

### Delegated responsibilities:
Copy link
Sponsor Member

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?

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
Sponsor 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
Sponsor 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
Sponsor 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.

- Members triage the project’s issues and pull requests.
- Member maintain and monitor the website including updating versions.
- Mentor new contributors to the website.
- Run or support djangoproject.com sessions in DjangoCon sprints.
- Chair, Co-Chair and Board Liaison can sign off on new features.

## Initial membership

- Chair: Sarah Abderemane
- Co-Chair: Saptak Sengupta
- Board Liaison (must be an active Board member; may be the same as Chair/Co-Chair): Sarah Abderemane
- Other members:
- Eric Sherman
- Mark Walker
- Jason Judkins
- Paolo Melchiorre
- Sanyam Khurana
- Tobias McNulty
- Ron Maravanyika



## Future membership

### 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. 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.

### 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 `website-wg@djangoproject.com`
Copy link
Sponsor Member

Choose a reason for hiding this comment

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

Could we set up a Google Form instead? From my experience with DSF mailing lists, it’s 99% spam that we receive on those emails.

It’d be nice for you to define here what kind of information people should provide when applying, rather than just expect applicants will figure it out.

Copy link
Author

Choose a reason for hiding this comment

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

@django/djangoproject-com-maintainters what questions must we ask if we are to build the form?

Copy link
Member

Choose a reason for hiding this comment

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

To be a part of this group, I think there should be a criterion to be a contributor to any project within the Django organization OR a member of DSF. I think then it makes sense to be part of the working group. Thoughts?

Copy link
Sponsor Member

Choose a reason for hiding this comment

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

I’d recommend "has to be a DSF member" as this is a clearly-defined status.

Copy link
Author

Choose a reason for hiding this comment

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

I second the suggestion to be a DSF member to join.

Copy link

Choose a reason for hiding this comment

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

I agree with "has to be a DSF member"


### How will decisions on adding/removing members be handled?
Direct membership: new members may self-nominate; the WG will vote (50%+1) to approve/deny new members. The WG will vote for New Chair/Co-Chairs and decision to appoint will be based on gaining majority votes.

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


## Budget
No allocated budget

## Comms
- Private channel in the DSF slack
- A mailing list that we'll create, `website-wg@djangoproject.com`
Copy link
Sponsor Member

Choose a reason for hiding this comment

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

Could you explain why you’re proposing a mailing list? They tend to run slow in my experience and are prone to spam. Django has a Discord server where we could have a private channel. The DSF has a Slack workspace. Could we use either of those?

Copy link
Author

Choose a reason for hiding this comment

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

Well this is open to discussion, maintainers can decided where they want comms to be. I just remembered that l got involved on the site through the DSF individual members mailing list so i just assumed.

Copy link
Sponsor Member

Choose a reason for hiding this comment

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

IMO, it would be better to use Django discord or DSF slack, discussion would be easier than email.

Copy link

Choose a reason for hiding this comment

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

Is there a DSF slack?

Copy link
Sponsor Member

Choose a reason for hiding this comment

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

I see we now have both the Slack channel and a mailing list. @ronnzw I think you need to define how each of those would be used, or if it’s open to discussion then explicitly write it here.

Keep in mind the more clear-cut the group charter is, the easier it is for people to consider joining and for the board to review. So if discussions need to happen, now is the best time to raise this question with interested members.

@jcjudkins yes, the DSF has a Slack Workspace for internal matters. Largely this has been used for paid employees, the board of directors, and a few working groups now.

Copy link
Member

Choose a reason for hiding this comment

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

IMHO slack works fine for the working group. Mailing list can be for discussion among larger audience.

Copy link
Sponsor Member

Choose a reason for hiding this comment

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

@ronnzw I think this one is the only missing update from your part according Thibaud's message

Copy link
Sponsor Member

Choose a reason for hiding this comment

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

I see "DSF slack" is now there so I’d just recommend removing the point about the mailing list and that’s it :)

Copy link
Author

Choose a reason for hiding this comment

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

Is everyone happy with me removing the mailing list? Despite a mailing list being included in the WG guidelines?

Copy link

Choose a reason for hiding this comment

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

I can see a mailing list being useful as a way of making announcements and interacting with the wider audience. But if we feel that might not be as necessary for Website WG, then removing the point about mailing list makes sense.


## Reporting
We'll email a written report to the board every quarter.