The recent work on our quick-start.html page by Pavel Lyalyakin prompted some thinking about how to better organize our site editing. Pavel asked about lightweight branching and Daniel suggested to copy site/publish to site/staging and having it served as http://subversion.staging.apache.org/ to facilitate previewing [1].
I think that's a great idea (I've sometimes wanted something like this myself, for instance when working on a difficult FAQ entry). So, if we'd have such a staging site, how should we use it? How about a very simple workflow like this? 1) Commit to staging. Other devs get the commit mail via the notifications@ list. 2) Wait for others to review (the commit mail is the notification that something needs to be reviewed). In case of large or sensitive changes, preferably send a mail to dev@ to draw extra attention. 3) If any other committer says +1, go ahead and "promote" (merge) to the live site. 4) If no response after 1 week? 3 days? ...? go ahead and promote to live site (lazy consensus). Small changes and corrections can go directly to the live site. Maybe we'll need some exceptions for things like news, release notes and security pages, which are usually updated as part of releases and get a lot of eyes already. Thoughts? [1] https://svn.haxx.se/dev/archive-2017-10/0004.shtml -- Johan
