Hi Ted, On Tue, Jul 30, 2024, at 14:42, Ted Hardie wrote: > Hi Lucas, > > Thanks for the reply. Given that reply, I think it would make sense for the > wg to see a more worked description of how the contribution mechanics would > work. As noted in my original email, my intention would be to follow the similar ways in how we use Github for drafts and wg-materials (minutes, slides, etc) using Issues and PRs.
I do not envisage the Web pages to contain resources that are formal WG items that requires consensus. We can and do link to those already on the appropriate datatracker and/or RFC editor pages. The chairs are already the party primarily responsible for triaging issues, reviewing PRs, and updating the quicwg.org source repo. Putting further content there seems like a natural extension to me. The goal would be a very light-touch process, focused primarily on not breaking things and maintaining a consistent style. > > At the moment, updating the wiki requires certain permissions for the repo; > if the end state after you've worked this out is functionally the same, then > this change doesn't really improve things and can probably be safely put > aside. The kicker is, GitHub wikis are just a (poor) UI layer over markdown files in a repo. Something many contributors, or would be contributors, are already familiar with. Sadly, the GitHub wiki appears to lack any form of access control, change control, review process or curation. To my knowledge, it is not even possible for somebody to easily propose an edit and allow the repo maintainer to vet it. This is pretty much the complete opposite to how the QUIC WG has used GitHub since day 1. > > > If there is a way to do this that allows "useful grass roots contribution > and maintenance" without similar permissions, it would be useful for the > working group to understand it when making this decision and also to document > that for other groups that might have similar issues. No hats: I struggle to see how completely free write access can work. Even the IETF's own wiki service at wiki.ietf.org has edit access controls based on datatracker login or by filing a GitHub pull request. When the wiki is vandalised, the only folks that can fix it are the people with write access. Ultimately that tends to land on the chairs to do. I think it's fair to prevent intentional or accidental damage before it happens, rather than to spend cycles tidying up. We were lucky that the vandalism was somewhat benign data deletion, it could have been something worse. None of the status quo is really documented as it evolved organically. Any changes are an ideal time to write more concrete ideas and processes down. I suspect the best format for doing that is a staging version of the website with some placeholder content. An alternative could be to migrate GitHub wiki content to e.g. wiki.ietf.org/en/group/quic. However, I'm not sure that addresses all of the pain points. And it will mean we still have content split between the quicwg.org landing page and a wiki. Another alternative is, of course, to do nothing and just leave things frozen as they are. I don't think that's a particularly good outcome for anyone though. Cheers Lucas > > Just my personal opinion, of course, > > Ted Hardie > > On Tue, Jul 30, 2024 at 10:36 AM Lucas Pardue <[email protected]> wrote: >> __ >> Hi Ted, >> >> On Tue, Jul 30, 2024, at 10:15, Ted Hardie wrote: >>> Hi Lucas, >>> >>> I think I am missing something fundamental here: >>> >>> I'd like to propose that we migrate away from using GitHub wikis for all >>> repositories in the quicwg org, towards using the quicwg.org pages. This is >>> intended to improve the contribution and change process. It is hoped that >>> this will also improve the discoverability of content on the wiki. During >>> any migration, content will continue to reside on the wiki. >>> >>> There is nothing on those pages that I could see that indicates how you can >>> propose a change to the pages. If the aim here is to enable "useful grass >>> roots contribution and maintenance.", I think it would be appropriate to >>> say more about how this migration does that, because I don't understand it. >>> The quicwg website doesn't even indicate how to contact the maintainers, >>> so it's hard to see how it enables a grassroots effort. >> Indeed, the current quicwg.org has been mostly operated by the chairs, with >> a small number of contributions from those that might have stumbled on the >> repo. >> >> Consolidating useful information to a single place would come with improving >> the documentation on how to contribute, whether it be an issue or a PR to >> the repo [1]. And of course, we would cover the requisite notes on >> contribution code of conduct and note well. >> >> Cheers >> Lucas >> >> [1] https://github.com/quicwg/quicwg.github.io >>
