Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
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
Initial Website working group proposal #10
base: main
Are you sure you want to change the base?
Initial Website working group proposal #10
Changes from 9 commits
812d3a9
5049cd5
15673f8
5e5bea1
02ebd0c
7948a8d
3c057b0
b83468a
4cd3a46
d17ba20
9bb86a7
b67af2d
d1a1def
8bb169d
e250616
0f205f7
7f6cdb5
06a804c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Yes 💯
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Permissions / access to resources:
@django/ops-team
on the pull request for deployment.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:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing removing members.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.