Process - Expedited mering of event page changes

[sweco-sedalh]

Feature Description

Not quite sure if this is an appropriate venue for this, or if it should be a QEP or similar, but I'll start here.

---

For event pages (as the UC 2025 pages just merged) there are usually three things true - there'll usually be one or two people responsible for updating them from the LOC (local organizing committee), other potential reviewers likely won't be able to tell the validity of the information (as the PR might be the first time they see it) and there commonly is an urgency (especially the days before/during the event, where changes need to get out ASAP) that's not applicable for most other changes.

Therefore, I think it would make sense for an expedited PR process. Something along these lines:

LOCs can appoint 1-2 persons who get permission to merge PRs, including their own, touching only the specific event pages. PRs touching other parts require the usual review process.

I don't think that Github supports branch policies scoped to directories (not even with a CODEOWNERS file), so this would have to be a "soft" policy (i.e. the appointed persons get the ability to merge any PRs, but must promise to follow the process).

Reference to Feature

No response

[timlinux]

Hi @sweco-sedalh thank you for your ticket. For me I prefer that we work through @Xpirix to manage merging PRs so that he can maintain review of everything coming in to the web site. If you follow the same approach as UC2024, you can establish your own event specific site (or just use the QGIS wiki - https://github.com/qgis/QGIS/wiki/) and then independently manage the content there. @Xpirix is very responsive and should be able to merge any PR's within a short period after it is opened.

[sweco-sedalh]

The current idea - having the UC-site as part of qgis.org - was the result of a discussion at the CM in Bratislava. Mainly it's about reducing the amount of work the LOC has to do (now, the following conferences just have to adjust the date, location and other details and send a PR, as opposed to setting up hosting (even if Github Pages makes it reasonably easy), DNS, syncing styling with QGIS at large, etc.). Secondarily, this can also help with visibility for the conference.

While I in no way doubt that @Xpirix does and will do his best, we don't want to put the additional burden/pressure of quickly (as in, within hours even outside his normal workhours, if there's something important shortly before or during the conference) reviewing changes.

I don't think splitting the information between more places is a good idea, so if this is possible we might want to reconsider how the conference pages are handled.

[timlinux]

hi @sweco-sedalh

Thank you by the way for organising the UC2025 and please don't take me to be obstructionist, but I am wary about putting all of the UC event content into the QGIS web site. We spent a lot of time trying to prune the site down to a more carefully curated set of content when we did the web site overhaul and if feels like hosting the UC2025 pages there will take us in the opposite direction.

Some solutions I would prefer:

1. Use the wiki - low effort and we used it for many years to organise events.
2. We could give you a separate subdomain e.g. uc2025.qgis.org and ask @Xpirix to create a blank copy of our hugo template there. Then you can manage content there as you see fit and we can take it offline again after the UC
3. Consider finding a tool for managing the conference e.g. https://getindico.io (just a randome google link, not sure how good it is) that could be used year on year so we can solve this over the longer term
4. If others don't agree with me about my position above we could perhaps use git submodules to delegate responsibility of some pages to you...