Current workflow:

• Make a patch
• Create a patch demo wiki with that patch (2 mins)
• Repeat until finished (5-10 mins)
  • Share it
  • Get feedback
  • Update your patch
  • Edit your patch demo wiki to update the patch

For trivial changes (e.g., make that button blue) 5-10 mins is a long loop (especially if the feedback following the loop is, e.g., maybe back that button green :))

Allowing limited, non-persistent editing of short-lived Patch Demo wikis could help and may be trivial with a small enough scope.

A.C.

• I'm able to make edits to the files in my wiki remotely without updating my patch
• Only wiki creator should be able to edit their wiki
• For this task:
  • edits do not need to persist following k8s events (e.g., scaling, eviction, etc)
  • does not need to be compatible with IDEs, necessarily or accept local edits (e.g., editing in a textbox is fine)
  • git operations don't have to work; e.g., getting a patch of what's been edited
• Only MediaWiki PHP/JS/CSS files may be edited, compilation changing dependencies/extensions, getting a shell—bonus points but unnecessary
• We should think about how to prevent folks from easily messing with AbuseFilter settings—currently we strip the user agent and the ip address before it gets to MediaWiki. But we've also turned off other javascripty AbuseFilter features in our LocalSettings.
  • Patch Demo is running code that is somewhat trusted (does require V+2) so making it hard to collect this data by accident is what we want
  • Post-config-edit linting/alerting could help here