deobald
commented
2 years ago 1. Avoid "&"
I'll push back on adding "&" to categories, wherever possible. As with user stories, systems thinking, and knowledge management, lumping classes of information with "and" leads to sloppy categories:
- Operations & Maintenance can just be Operations (Maintenance is implied) -- this is just renaming "Administration"
- Runtime & Storage ... I'm not sure why we'd relate these two things? As a user, whether the databases I'm interested in support Byte Array storage and whether they run on Graal are two unrelated features.
- Query & Data Model -- I buy this lumping, but it would be better if we could find one word that captures both. I'm also worried that with @quoll's input (once she's back online; she's snowed in without electricity at the moment) the "Query" section will get much larger, though I suppose that has the nice benefit of allowing us to break "Query" apart from "Data Model" at that point.
2. APIs
I'm not sure this is enough to justify its own category (the only rows I see are Java, HTTP, and remote client). It also doesn't feel like a category that would grow over time as people add features to their Datalog dbs. Unless perhaps we included client libs and drivers in here and people started building up non-Clojure front ends to APIs? Then I buy it.
3. Where did "Transactions" go?
This is the second-largest category, behind Query. The category was intentional and I wouldn't roll its contents into any of the proposed 4 above. As a db user, I would want to know how I insert data into the database and how transactions are handled, separate from all these other topics. There are also a lot of weird transaction semantics to Datalog dbs that users coming from an RDBMS background will appreciate having collocated in one place, I think. ("Just what the heck is a composite tuple or a transaction function, anyway?")
4. Consoles
I don't think the consoles go under "Administration," (or the proposed "Operations ~and Maintenance~") since they don't pertain to administrating an environment (one hopes). They're a developer experience almost by definition. I'm not sure where they'd go under the proposed categories.
5. Repeated section headings
Also, given the section headings, the column headings should probably be repeated each time to avoid forcing people to keep track of which column is which.
Makes sense.
Summary
Maybe it would be better to make these changes piecemeal, rather than sweeping changes through a new PR? It would also be nice if they were driven by the community, rather than by us, since that was the entire goal of reorganizing the rows into collocated categories.
Currently (since https://github.com/clojurelog/clojurelog.github.io/commit/dabebc331269d19eac9ef8a0cc78a91be0852dee) the sections are:
However, there are a few categorization anomalies, like including the clj/s runtimes under "Developer Experience", or having the consoles not under "Administration".
I propose:
If those don't seem obviously problematic (looking for feedback @deobald :slightly_smiling_face:), I will draft a PR with the full set of changes.
Also, given the section headings, the column headings should probably be repeated each time to avoid forcing people to keep track of which column is which.