Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved Sections #10

Open
refset opened this issue Jan 4, 2022 · 1 comment
Open

Improved Sections #10

refset opened this issue Jan 4, 2022 · 1 comment
Assignees

Comments

@refset
Copy link
Contributor

refset commented Jan 4, 2022

Currently (since dabebc3) the sections are:

  1. Storage
  2. Transactions
  3. Query
  4. Developer Experience
  5. Administration

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:

  1. Runtime & Storage
  2. Query & Data Model
  3. APIs
  4. Operations & Maintenance

If those don't seem obviously problematic (looking for feedback @deobald 🙂), 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.

@deobald
Copy link
Contributor

deobald commented Jan 4, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants