Hi Sam, FWIW, I don't have much time to work on Whimsy at the moment but I'm interested in keeping track of what's going on and help with the design whenever that makes sense. Especially around helping make the Board's work more asynchronous.
If I end up writing some code, I'm more familiar with JavaScript than Ruby but far from being an expert, I could do some small things in both languages. I have one comment on the /public data that you mention. On Thu, May 7, 2020 at 12:58 AM Sam Ruby <ru...@intertwingly.net> wrote: > ...Instead of having shared libraries for parsing committee-info.txt, there > can be a canonical JSON file for this data, and multiple tools can have > file watchers that trigger when this file changes. > > In fact, we already have these types of files; you can see them in > https://whimsy.apache.org/public/. We can create some more and put them > in a private director... I like this design a lot: provide a set of canonical read-only data files that are easy to understand, with models that "never" change (Famous Last Words) and update the files automatically when the source data changes, providing a way to observe those changes. On public vs. private I suggest creating multiple private folders to define who can read what, like private/members, private/board etc. It's then easy to use standard HTTP access control on those folders and makes it very clear what's what. Serving that data from a specific subdomain like data.whimsy.apache.org might help with statistics and if data use grows it's good to have the simplest possible thing serve it, whereas Whimsy itself needs more machinery. -Bertrand