I think we sorta agree on naming conventions. Smaller packages have single core feature or serve a focused purpose should have clear-cut names. Larger packages, or even “modes”, with a variety of core features, should have more vauge, clever names that invite users to explore more and set the expecation that there might be a few things to learn.
The disagreement is perhaps where O-R lies, or will lie in the future. Will it be just backlinks focused, or will it become more of a knowledge management package with more core features? I don’t think anyone can predict that accurately, so I made a educated guess using the roadmap. I think in the current stage org-backlinks is certainly the better, more accurate name.
If it’s worth anything, other than org-backlinks, I do like ergo more than any of the other suggestions.
Edit: I’m not sure about names stifling development, it certainly doesn’t seem devs (and espeically Emacs users) care all too much about the “intended” use of software !
Yes, we’re definitely more in agreement than disagreement.
Thanks for your perspective. I hope other people can weigh in so we can look at this from a variety of angles.
Tangentially related:
Ergo => Therefore sign - Wikipedia lots of potential for logos. The asterism in particular looks ripe for good designs (stars for Org, arranged in a therefore for Ergo).
⁂
In observational astronomy, an asterism is a popularly known pattern or group of stars that can be seen in the night sky. This colloquial definition[a] makes it appear quite similar to a constellation,[1] but they differ mostly in that a constellation is an officially (as in, by the IAU) recognized area of the sky, while an asterism is a visually obvious collection of stars and the lines used to mentally connect them
Even fits in with the knowledge discovery theme of linking ideas in the night’s sky of one’s notes! (And could double as a nod to Org’s author, Carsten Dominik’s astronomy background! Lots of possibilities here)
Asterism (as a name) could also serve, as a group of related notes. While not super clear (just as as @rooster said for org-mode, and we use it daily) it opens many possibilities.
If it were just a descriptive name we should thing about the core description, like linked-notes or something like that. It’s precise and understandable.
However, for a broad and flexible mode as O-R, I personally prefer something more inspiring like Asterism. ;D
I think it should start with ‘org-’ like other org add-ons tend to. I like ‘ergo’ by itself, but ‘org-ergo’ is awkward to say and sounds like ‘or-ger-go’.
I’ll suggest ‘org-zk’, and I like ‘org-notes’ best of the above alternatives. It sounds different enough from ‘org-noter’ that I don’t think confusion is too likely. ‘Org-backlinks’ isn’t bad either, but it implies a much more limited scope for the package than it actually has.
The main argument I’ve heard in favor of using the prefix is that it increases discoverability. However, if a package’s metadata is written properly (mentions Org in it’s description and keywords) it’s equally discoverable in MELPA and through package.el without the prefix. Flouting that tradition actually makes a package stand out in a sea of org- prefixed packages. For example, my package, doct. First page on MELPA when you browse “org”:
23rd out of 336 packages.
Had I named it org-doct or something similar it’d be sitting on the 3rd page at around the 139th package- at right about the point where anyone browsing (org-if org-they org-browsed org-that org-far org-at org-all) org-would org-inarily org-be org-numb.
Even so, discoverability mostly boils down to word of mouth and usage with Emacs packages. Packages need advocates- people who care enough to use, share, and improve them.
I’m not aware of any technical argument for using such a prefix. If anything the technical argument from a developer’s perspective is in favor of using a shorter prefix. Prefixes are a necessary evil, as Elisp does not have proper namespaces yet. The longer the prefix the more of a burden it is to type, read, and reason about. Imagine a recipe that referred to every ingredient with similar prefixes:
"Peanut Butter & Jelly Sandwich"
Ingredients:
- 2 ingredient-slices ingredient-bread
- 2 ingredient-tablespoons ingredient-peanut-butter
- 2 ingredient-teaspoons ingredient-jelly
Directions:
Spread ingredient-peanut-butter on one piece of ingredient-bread.
Spread ingredient-jelly on the other piece of ingredient-bread.
Combine ingredient-bread-peanut-butter with ingredient-bread-jelly.
(optional) Cut crusts off of ingredient-sandwich-bread-peanut-butter-bread-jelly.
Enjoy ingredient-sandwich-bread-peanut-butter-bread-jelly--crust-maybe!
Even for a simple recipe it becomes cumbersome quickly.
If there is another reason to stick with the org- prefix, I’m open to hearing it, but I have not come across anything convincing.
I assume the zk is for zettelkasten, which IMO artificially limits the usage of the package. We’re not strictly adhering to the zettelkasten method as far as I can tell as well.
To me this one feels like an understatement of what the package can/does enable.
Imo, just keep it org-roam and don’t bother with the renaming. At most what could be done is an explicit disclose that the project is not anyhow connected with RoamResearch, but only somehow inspired by it.
Sure, and I agree. There is no hurry and no need right now.
However, if this keeps flowing as a slow undercurrent, when the time is right, the name will be there.
If not, we may have to decide on a hurry.
BTW, if we are pointing to a core concept of this, at least in my mind, Memex is the core.
Probably many of you have read the original article: https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/
In my case, it’s one of the reasons I started with hypertext at the end of the 80’s.
While I don’t have a particular stance on a name change, I think one key consideration is discoverability. Org-roam is memorable and easy to search, while Ergo could bring up a whole host of irrelevant results. The audience is definitely not big enough to make it the number 1 result if there were any products with similar names.
There seems to be a fair amount of support for keeping the current name and no agreement on a replacement. I like “Ergo”, but I have another project which I can use that name/logo concept for. I rescind my suggestion.
I don’t feel very strongly about the name for org-roam, but just wanted to give a thumbs-up to @nv-discourse on ‘ergo’ and the logo - I like that a lot for something!
The name for this project needs to change ASAP. The fact of the matter is this project touts itself as a free “replica” of a commercial product (Roam by Roam Research).
Potential customers of Roam are 100% being diverted to org-roam, which gives Roam Research every incentive to pursue litigation.
If I go to https://www.orgroam.com/ the first thing I see is a giant logo that says “ROAM” on it. ROAM not ORG-ROAM.
So we have software that is a “Roam replica with Org-mode” that is using the ROAM trademark in it’s logo. (Trademark in the U.S and many other countries is typically first to use, and it’s hard to argue it operates in a different category, specifically when org-roam directly touts itself as a replica.)
Imagine creating org-netflix, saying it’s a free replica of Netflix, and then creating a website that has a giant logo that has just the words NETFLIX on it.
It is BEGGING for ligation.
This project has a lot of potential, but change the name now – change it yesterday, before it becomes a bigger issue.
Agree with you. And I can tell you a “funny” story. I know Org since many years, but when the first person mentioned “org-roam” I was thinking it is an extension to manage sharing Org-files between different machines (like roaming in a cellphone context). Yes, never heard of Roam or org-roam before and so it was not intuitive to decipher what org-roam really is. Meanwhile I found out, nevertheless.
!
