Define the brand name of the project

[zlatanvasovic]

I noticed many names are used for this project, so I think it should be clarified. For example, you can find TL;DR pages, tldr, tldr pages and TLDR pages in various documents and website.

My suggestion is to use and tldr for the name of npm package and TLDR pages or tldr pages for everything else. How does that sound?

[leostera]

tldr(.sh) > miniman > anything else > tldr[-]pages > howto

That’d be my short answer. So if we ain’t sticking to tldr for legacy reasons, I’d friggin love miniman to be the name.

[waldyrious]

Great comment, @ostera. For a moment I was tempted to convert the other comments into a similar ranking for each participant in the discussion, tally up the votes and provide a table with numbers and total scores according to various ranked-ballot counting methods (Borda, Schulze, etc.) — however, in my experience making these decisions based on cold numbers ends up feeling empty and unconvincing to most participants.

I believe at this point it is possible to identify a consensus (even if not unanimous) in the community, so I'll leave it to @rprieto to make the final decision.

(Note that the effects of the decision will likely not be effective immediately — we'll need to then start discussing a transition plan, to avoid doing things too hastily.)

[leostera]

I'd like to bring this from the other discussion, that I feel is very relevant to this conversation as well

Being playful and maintaining quality is a hard balance to keep, but so far we’ve done great work on curating these pages. Don’t see why we couldn’t try and check how the numbers do...after all Any rebranding is done to increase awareness and pull the brand value up ☝🏼 — @ostera

So keep in mind that this is a branding discussion.

[zlatanvasovic]

Seems like this has been solved.

[waldyrious]

@zdroid I guess you're referring to the discussion at #2986. That one is about visual identity more than naming, as this one was. I will update the title of both issues to make that distinction clearer.

That said, re-reading this discussion, I feel that, while there were valid and even compelling arguments for a rebranding towards "miniman", the overall sentiment in the thread is one of strong attachment to the "tldr" name, so it makes sense to keep that in the core of our branding.

Still, I do bump into the issue of awkwardly having to refer to "tldr-pages pages" all the time, and people in the thread were not too keen on the usage of a hyphen to make the project name stand out as a single word, so I would suggest fully embracing the tldr.sh name. I'll reopen this issue to allow us to make a decision on that regard.

So, question for all those who were involved in this discussion (@zdroid, @ostera, @rprieto, @agnivade, @Leandros, @ericbn, @rubenvereecken, @mflint, @sbrl) as well as more recent members of the org (@mebeim, @pxgamer) and everyone in the community:

In light of the discussed above, what do you guys think about consolidating tldr.sh as the project name?

Please use the reactions so we can gauge the overall sentiment more easily: 👍 👎 (or 👀 if you have no strong preference and prefer to remain a neutral observer).

[mebeim]

I've seen this project almost always being called "TLDR pages" (with a variation of the case e.g. "tldr pages", "TLDR Pages" etc). I don't recall seeing any client referring to it differently. This project has been around for quite a while and this name is spread among countless repos, clients and documentation pages. I would therefore vote for "TLDR Pages" (or variation of the case) if I had to. Furthermore, "tldr.sh" just feels like a domain name to me.

[agnivade]

There was no neutral reaction button, so I put "eyes" on it. As a single short name, "tldr.sh" is okay .. I guess. But as you can see .. there are concerns being raised with it looking like a domain name.

[waldyrious]

Good point, @agnivade, I added that option above :)

As for looking like a domain name, I don't see why that's a bad thing; quite the contrary, it helps solidify the branding and is one less thing to memorize. Besides, it's shorter, more distinctive, and works as a single word (Incidentally, I find it interesting that a domain, rather than a shell script, is what the .sh extension evoked!)

I do want to hear about your experience with referring to the project's pages, due to the inherent duplication of "tldr pages page". Does that not bother you at all? If we decide to stick with "tldr pages" as the project name, maybe we could call the pages something else (files? documents? entries?), which would resolve the situation in a different way.

[mebeim]

@waldyrious if the name is "TLDR pages" then a single page would be called either "TLDR pages page" or "TLDR page" (or maybe even "page of TLDR pages". It of course depends on the context though. There surely is no need to prefix it with "TLDR pages", most of the times it can be clearly understood what the term "page" refers to.

[mebeim]

Also, adding to my previous comment: the project's organization GitHub name is "tldr-pages", which would make naming it differently rather confusing to me, so there's that.

[agnivade]

We would have to rename the org of course. Github will redirect old links pointing to the old org - https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization.

[owenvoke]

The only issue is that anyone can then take the old org name. 🤔

[leostera]

At the risk of stating the obvious, remember the org name has tons of searchability value attached to it already.

Can you ask GitHub for a org level redirect?

[agnivade]

The only issue is that anyone can then take the old org name

They indeed can. But links to old repos will automatically redirect. Only a link to the exact org - "github.com/tldr-pages" will now point to the newly acquired org.

See the link above.

[mebeim]

At the risk of stating the obvious, remember the org name has tons of searchability value attached to it already.

This.

Also not sure if renaming the org would also break script/code/auth tokens/clients and whatever else uses that name to do anything. Is GH "redirecting" the old name forever?

---

EDIT: ok just looked at the link above, this would definitely break half the stuff and most of the clients:

After changing your organization's name:

• Links to your previous organization profile page, such as https://github.com/previousorgname, will return a 404 error. We recommend you update links to your organization from other sites, such as your LinkedIn or Twitter profiles.
• API requests that use the old organization's name will return a 404 error. We recommend you update the old organization name in your API requests.

[agnivade]

Yep, so only the exact link and the API requests will return an error. Github will redirect everything else.

[waldyrious]

Evidently we wouldn't simply swap things around all of a sudden, unannounced. This change would have to be synced with client maintainers.

Also, we could re-register the org name if we wanted to set up renaming notices or prevent others from taking over the name, etc. Look, none of this is meant to be painless or easy. But we are a capable and technically competent community -- I don't think we should be stopped from taking this sort of decision based on possible technical challenges of a project rename. If we do think the current name is better, even assuming a transition to another name would be completely seamless, then it's fair to stick with it on its merits -- but let's not do so based merely on the technical difficulty of adopting an alternative.

[mebeim]

@waldyrious valid point. I genuinely think the current name is better though.

[sbrl]

Personally I've always used tldr-pages myself. I agree with @mebeim and @ostera here personally.

[zlatanvasovic]

@waldyrious I'm not completely for .sh extension since it's generally used for projects developed in Shell only. However it nicely indicates the project's use, and that's a big plus. :+1:

[waldyrious]

Personally I've always used tldr-pages myself.

@sbrl the problem is that previous suggestions (in the older comments of this thread) to use a hyphenized form were met with a lukewarm reception, so unless we can swap that sentiment, we'd be stuck with the awkward two-word, unclearly separated "tldr pages". Any thoughts about that? 😕

[mebeim]

What's the hyphen thing? Whether to use "tldr-pages" or "TLDR pages" would of course depend on the context. If we talk about the GH repo/url user we say "tldr-pages", otherwise "TLDR pages". I don't see a problem.

@sbrl are you suggesting to use "tldr-pages" as the project name instead of "TLDR pages"? That wouldn't make sense IMHO.

@zdroid how does .sh indicate the project's use? .sh makes me think of a shell script, not a collection of manual pages. Could you elaborate on that?

[zlatanvasovic]

@mebeim for me it's more indicative of being used in shell. I have to say tldr-pages sounds more like print publication than a computer program.

[waldyrious]

If we talk about the GH repo/url user we say "tldr-pages", otherwise "TLDR pages".

@mebeim please note that at the start of this thread there was some discussion aboout using the capitalized version, and the consensus seemed to be that the lowercase version was preferable.

[mebeim]

@waldyrious I was just differentiating between the two alternatives with or without hyphen, I already said that case wasn't important for me.

[zlatanvasovic]

Reviewing most of the project's repositories, it seems this and #1192 are the omnipresent issues. Website, docs and clients all have own version of brand name and description.

I suggest we focus on these two (quite correlated) issues over any other, in order to finally move on. The issues hurt the project's branding, promotion, portability (clients) and on top of that, confuses everyone involved. However, I am sure we'll be able to solve this as soon as possible. :hugs:

To add my final two cents, the easiest way to go is to keep the project named tldr pages, as it's simple and effective. tldr itself stays the name of this repository (and thus its content), aswell as the name of individual clients (e.g. npm package tldr). Any variant including capital letters (TLDR pages, dots (tldr.sh) or even worse, semicolons (TL;DR pages) makes project's name inconsistent over different platforms, since those aren't suitable/supported in all situations.

[zlatanvasovic]

ping @waldyrious @mebeim @agnivade @pxgamer

(it seems @sbrl agreed with the point)

[mebeim]

@zdroid I don't think capitalization is a problem, but I nonetheless agree that "tldr pages" should be the name as I already said in previous comments.

[agnivade]

I have already given my opinion above. I am neutral.

[zlatanvasovic]

So we agreed on this? Maybe it's the time to close the issue?

[mebeim]

@zdroid doesn't seem like we all agree to me, I think the majority prefers "tldr pages" but I'm not sure, cannot read all the history now.

[zlatanvasovic]

I meant the majority of course, it's quite impossible everybody completely agrees on something.

[sbrl]

See this comment and this comment @zdroid :-)

[waldyrious]

I'll give a shot at summarizing the main points of the discussion above (I'm interpreting consensus as no strong objections):

• Semicolon: there is consensus to not use it (so tldr instead of tl;dr)
• Capitalization: there is consensus to use lowercase (so tldr instead of TLDR)
• Rebranding: no consensus to change. The closest alternative that garnered some support was "miniman", but there was opposition due to the "tldr" name being too ingrained now. Even the proposal to make a softer change towards "tldr.sh" had a lukewarm reception, with no clear preference.
• Hyphenization: no consensus. Using a hyphenized form was proposed here and here, but was argued against here; additional signals (comments, reactions) did not accumulate significantly in favor either approach.

Gathering a more global view of what has been discussed, I'd say there are only three alternatives with any chance of being adopted:

1. The progressive option: Biting the bullet and making the change to miniman, with the understanding that there are potential downsides but they are manageable, and balanced out by the upsides (including enthusiasm by various community members, even the project creator!);
2. The moderate option: Consolidating in tldr.sh as a simpler, shorter and more distinctively brand-like name, that still preserves the main identity of the project;
3. The conservative option: Sticking with tldr pages (this exact spelling: no capitals, no semicolon, no hyphen) as the evil we know, to avoid the inconveniences of changing the name and benefit from the historical weight of the name.

I must admit 😢 that option 3 seems to be the only one that nobody objects to, so if you guys agree this assessment is correct, we can close the issue with that decision.

I would only ask for a compromise in order to reduce the "tldr pages page" issue: can we start referring to each individual file as an "entry" rather than a "page"? That's not part of the branding itself, but would greatly facilitate it, and would remove the ambiguity of the project name being "tldr pages" vs. "tldr".

[sbrl]

Great summary @waldyrious! This is indeed a thorny issue. Personally I've always called it a "tldr page", but a "tldr-pages entry" would be fine too. If this is the case we should update any documentation where this is referenced.

I've always used tldr-pages myself, but that's only because that's the name of the org.

[zlatanvasovic]

It doesn't seem wrong to use the term page(s) for the actual pages. tldr pages as a project is basically a collection of those pages. The more terms we add, the more complicated documentation becomes. I'm against defining more terms such as entries.

[waldyrious]

@zdroid please note that the suggestion of using "entries" is not frivolous: it's only to overcome the existing issue of referring to an individual file as a "tldr page" (which is ambiguous by making it seem like the project's name is "tldr" alone, which is precisely the type of confusion this issue was created to address) or as "tdlr pages page" (which is very awkward and essentially unusable).

That's one of the reasons I was hoping for alternative project names that didn't include "pages" in the name (i.e. tldr.sh or miniman), because those would automatically avoid the issue. But if we can't agree to make such a change, then the issue needs to be addressed elsewhere, hence the proposal to use "entries".

[mebeim]

I think you summarized that pretty well @waldyrious. I don't think I've ever referred to a page as "tldr page". Why not just use the word "page" alone? It probably depends on the context, but I don't really see this as an issue.

[waldyrious]

Why not just use the word "page" alone?

It's very context-sensitive and would make it hard to talk about tldr pages among other page-like entities (e.g. man pages, actual pagination of content, etc.)

Of course, we can live with the ambiguity (we have done just that so far); I was just suggesting a way that we could get rid of it without much effort (IMO).

[zlatanvasovic]

@waldyrious It's the same way for man pages and I don't see them having any issues. The command is called tldr (just like man) and its pages are called tldr pages (just like man pages), which is what the project mostly is.

[waldyrious]

That's a good point. I don't agree that there are no issues, as I described in several comments above, but I can accept that they're not super-problematic. Do you all prefer keeping "page" as the name of each entry, then?

[mebeim]

@waldyrious I do, I don't think other options would help that much.

[andrik]

@waldyrious

I see your point but I think we could keep page

[zlatanvasovic]

To be fair, this seems to have already been decided. tldr pages is the standard name for the whole project, and tldr for this repository and the command-line clients. I'm in for closing this and moving on with more important issues.

[agnivade]

Sounds reasonable to me. I just did a quick scan of the last couple of comments, and it seems like the discussion was about what to call a single item in our repo - and that seems to have converged on "page".

To conclude:

• Project name remains as - "tldr pages". Exact spelling, no semicolon, no hypen, and not just "tldr" too.
• A single item in the project will be termed as a "page". Similar to man pages, a page here implies a page from the "tldr pages" project. Short and simple.

Thanks everyone who participated in this, and special thanks to @waldyrious who took a lot of pain in steering the discussion in a coherent way ! Really glad to see how this turned out.

[waldyrious]

Thanks guys for wrapping this up. I think we need to remove the remnants of the semicolon, right? I know it's present in the banner; do you know if any additional instances remain?

There are also a bunch of instances of tldr-pages (with hyphen) which need to be updated:

https://github.com/tldr-pages/tldr/blob/master/CLIENT-SPECIFICATION.md#L5

https://github.com/tldr-pages/tldr/blob/917c3eaa554a2ba8e30499b1aeece043e948b5aa/COMMUNITY-ROLES.md#L29

https://github.com/tldr-pages/tldr/blob/917c3eaa554a2ba8e30499b1aeece043e948b5aa/MAINTAINERS.md#L3

https://github.com/tldr-pages/tldr/blob/917c3eaa554a2ba8e30499b1aeece043e948b5aa/GOVERNANCE.md#L3

https://github.com/tldr-pages/tldr/blob/917c3eaa554a2ba8e30499b1aeece043e948b5aa/CONTRIBUTING.md#L23

https://github.com/tldr-pages/tldr/blob/917c3eaa554a2ba8e30499b1aeece043e948b5aa/CONTRIBUTING.md#L23

https://github.com/tldr-pages/tldr/blob/917c3eaa554a2ba8e30499b1aeece043e948b5aa/contributing-guides/maintainers-guide.md#L4

Finally, there are some places where TLDR is still spelled in all-caps, such as the website at https://tldr.sh, the copyright notice in the LICENSE.md file, the description of the tldrl.md page, and likely others.

Let's keep this open to track the harmonization in these places (and any others I may be missing), WDYT? It should be a quick fix now that a decision is made :)

[agnivade]

Thanks @waldyrious. That sounds great. Let's open a new one ? This issue is already overloaded with discussion on the brand name. I think a new issue to track the changes to be made might be more clear.

[zlatanvasovic]

@waldyrious I suggest you open a PR with that change. You don't have to work on it extensively, as the other contributors can finish the job. :) Also, the descriptions of other repos in this org should be updated.

[waldyrious]

Makes sense @agnivade. I'll work on this tomorrow night, time permitting.