Closed GaryJones closed 11 years ago
This convention was mainly for reasons that aren't necessarily code related and I should probably standardize across all my work for the PSR-0 compliance at the very least. My preference would be for no separator.
BlazerSix
for package and class names, blazersix
for everything else. Is that the standard approach for multiple vendor names with multiple words?
I typically use the Blazer Six prefix on project names for more common utilities that we build for internal use, otherwise, it'd probably use something a little more catchy. If we are going to break the repo by removing the dash, it's the time to decide whether a better name is in order.
BlazerSix
for package and class names,blazersix
for everything else.
That's exactly what I would go with.
Is that the standard approach for multiple vendor names with multiple words?
Most of the WP companies I can think of seem to use one name, or have a unique enough initials across multiple names to use that instead. Crowd Favourite is one that has two words, but they don't tend to use the name in a programmatic-sense - either they use cf, don't document at all, or they use the plugin name as the prefix.
In that case, it may make more sense to pick a non-company plugin name, ideally one word, for which the repo slug is also still available. As things stand, the plugin hasn't gained too much traction yet - only your end-of-year post is likely to link to it, and there's only a few stars on this project.
Thanks for that info. I'll start using those conventions instead.
I'm usually not a fan of the company name in project names, don't think it encourages collaboration, and don't want to receive all the credit for other's contributions, so I'm leaning towards renaming at this point.
The WP repo plugin slugs of "gist" and "gists" are both available. We could go really simple with the naming.
What about "Gist Embed" for a little clarity or "Gisto" for something kinda catchy?
Both available. I think a / the non-technology name ("Embed" may not imply that there's a shortcode feature available too, or that the embed just adds in a <script>
tag). may be better.
Not sure what the "a /" means here. I'm hesitant on Gist/Gists just because they're ripe for conflict with other code and could be confusing for end-users that might think the plugin was associated with GitHub (although I'd expect the audience to know better in this case). Just looked up "Gisto" in the search engines and it looks like there's a band with that name.
WP GistEmbed + ?? :)
Why didn't I think of that?
Just a suggestion :)
You guys have some good work here!
No need for a WP prefix - it's clear it's going to be a WordPress plugin.
There's already a "Gisted" plugin, but no "Gister", "Gistable" etc.
Hi Gary,
Only reason I added the WP was it seems to give people a sense of legitimacy and confidence. I have no idea why though, because as you say it's clearly a WordPress plugin. It does seem to me that plugins with a WP prefix do get more download than those without the prefix, and therefore more community support.
Anyway, you guys do great work and I for one appreciate it. :)
Either Gister or Gistable work for me.
Thanks for chiming in Bruce, and the compliments are appreciated!
@WebEndevSnippets - I agree with your observations, but it also seems like a lazy solution for getting a plugin name. Thanks for the compliment - hope you can make use of the plugin :-)
Thinking aloud - any thoughts about Re-gist-er? (though still isn't really a single word, which brings us back to the original problem)
I think it'd be a little difficult for people to share with the punctuation and it looks like it'd have something to do with user registration.
Combine Gist and oEmbed into something like "Gistom?"
GistPress looks like it's available.
GitHub project name, class names, and file names all use
blazer-six
orBlazer_Six
.Text domain, filter names, function names, package name, style sheet option name all use
blazersix
orBlazerSix
.These should ideally be standardized to use a separator or not.
As a non-employee, my preference would be to keep the vendor prefixes and identifiers as a single word (capitlized where suitable), otherwise PSR-0-compatible directory structure would have folders called Blazer with a subfolder of Six, which isn't logical in this case.