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 9 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
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
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
- Ensure that information on the website is accurate

Based on group discussions today, would recommend taking this out so it’s clear the group is meant to focus on features and code, and so we don’t have to figure out how to delegate access to the Django admin.

- 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

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

- 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

### 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 `website-wg@djangoproject.com`
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 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
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"

Copy link

Choose a reason for hiding this comment

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

@thibaudcolas I discovered yesterday during the WG conversations that I am not yet a DSF member, but I have now been nominated. If that nomination goes through, and if this proposal is not yet finalized by that time, could you add me to the initial Working Group membership, please? Thank you!


### How will decisions on adding/removing members be handled?
Copy link
Member

Choose a reason for hiding this comment

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

Missing removing members.

Copy link

Choose a reason for hiding this comment

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

I think after the one year term, anyone who doesn't opt-in to continue being involved in the WG can be removed. (We can also do an opt-out instead of opt-in mechanism. I don't have a super strong feeling about either). Also, I feel, maybe violation of code of conduct can result in removal of a member?

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
No allocated budget

## Comms
- Private channel in the DSF slack
- A mailing list that we'll create, `website-wg@djangoproject.com`
Copy link
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
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
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.

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

Copy link
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.

Copy link
Member

Choose a reason for hiding this comment

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

We discussed this at today’s DjangoCon US sprint meeting, with @jacklinke @tobiasmcnulty @pauloxnet @CuriousLearner @jcjudkins @bmispelon @thibaudcolas @jbeimler. Almost everyone in this group already uses Slack and will be happy there. No objections to having a mailing list in addition if this feels helpful.


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