project renaming

[mr-c]

While 'khmer' is a clever name for a nucleotide sequence k-mer-counting-based set of analysis tools it isn't appropriate in a global context.

Renaming an entity that is already somewhat well known is not an easy thing to do and will only get harder with time. I think the upcoming 1.0 release is an excellent opportunity to introduce a new brand.

I think the criteria for a new name should be:

1. Short
2. no clashes with an existing tool
3. doesn't appropriate from another culture

Playing with a morpheme-based name generator[0] I came up with the following list:

atsu
akour
oxli
dyirt
enki
fune
zaph
olon
nonfy
cerun
reont
qgy
epiro
tyvet
obirt
umgra
zoag
tosis
katavi
kero
airty

And 'dynaseq' as an 1980's tech reference :-)

[0] http://www.wordlab.com/gen/morpheme-machine.php

I am very open to other suggestions and comments.

[camillescott]

khaos!

[mr-c]

Things that will need to be renamed / redirected

the codebase & docs (this passes all the tests):

for item in `git ls-tree --full-tree -r HEAD --name-only`; do if [[ -f ${item} ]]; then sed -i 's/khmer/NEWNAME/g' ${item}; fi; done
for item in `git ls-tree --full-tree -r HEAD --name-only | grep khmer`; do if [[ -f ${item} ]]; then git mv ${item} ${item//khmer/NEWNAME} ; fi; done

the repository
the RTD site
PyPI
khmer-project@idyll.org

[ctb]

Also, all of khmer-protocols.

[ctb]

And all of the mailing lists.

[LSheneman]

@ctb would you like to talk about this from a marketing stand-point?

[ctb]

On Wed, Mar 12, 2014 at 02:06:27PM -0700, LSheneman wrote:

@ctb would you like to talk about this from a marketing stand-point?

I am most interested in the question of when to change the name at the
moment. Did any particular pros or cons of changing the name sooner rather than
later come up at the meeting?

--t

C. Titus Brown, ctb@msu.edu

[camillescott]

My thoughts: sooner is better. We have several papers potentially coming
out soon, where it would be good to have the updated name if it's going to
happen eventually anyway; further, as our presence grows (greater adoption
of protocols, open marine transcriptome(?), ++NGS course), I would expect
our reach to expand > linearly. More people to reach means more difficulty
getting the word out, more online presence via retweeting, refs in blogs
etc, and changing the name in published papers is difficult to impossible.

On Wed, Mar 12, 2014 at 9:00 PM, C. Titus Brown notifications@github.comwrote:

On Wed, Mar 12, 2014 at 02:06:27PM -0700, LSheneman wrote:

@ctb would you like to talk about this from a marketing stand-point?

I am most interested in the question of when to change the name at the
moment. Did any particular pros or cons of changing the name sooner rather
than
later come up at the meeting?

--t

C. Titus Brown, ctb@msu.edu

Reply to this email directly or view it on GitHubhttps://github.com//issues/320#issuecomment-37489230
.

Camille Scott

Department of Computer Science and Engineering
Lab for Genomics, Evolution, and Development
Michigan State University

camille.scott.w@gmail.com

[ctb]

If we were talking about this 2 or 3 months before release 1.0 is planned,
I'd be more positive about the idea of changing the name.

Instead I see a massive amount of short-term confusion being generated, a
lot of instability in the online presence (which people are currently
relying on), and a discontinuity for people using khmer -- plus, I expect
a significant amount of the next few weeks work would be on dealing with
the name change. I think 1.0 would suffer quite a bit due to this.

Implicit in this is that I don't see 1.0 as a particular milestone in
our online presence; it's not like all of a sudden adoption is going to
shoot up, or people are going to be suddenly super impressed by a 1.0
release. Adoption is still going to be driven by research needs and
documentation, not by what we're calling it or the fact that it's version
1.0.

My counter proposal is to roll out 1.x under the khmer name, and make it a
stable and good codebase. Then, when early 2.0 work begins, fork the
repository over to a new name and document it appropriately. Since I expect
2.0 to swizzle around the script names and API, it's a fine time to make a
break with the 'khmer' name. This would be in ~1 yr, presumably.

And, for the papers (hopefully) coming out soon, we're not going to be changing
the name in anything that's already mostly written, regardless of what we
decide.

I just don't see a strong reason to hurry, and I am against doing things
fast (or at least without long thought) largely on principle, which stems
from being an old fart with lots of experience... things done at the last
minute are typically done poorly.

So, so far, that's my opinion.

[camillescott]

Instead I see a massive amount of short-term confusion being generated, a
lot of instability in the online presence (which people are currently
relying on), and a discontinuity for people using khmer -- plus, I expect
a significant amount of the next few weeks work would be on dealing with
the name change. I think 1.0 would suffer quite a bit due to this.

Definitely fair.

Implicit in this is that I don't see 1.0 as a particular milestone in
our online presence; it's not like all of a sudden adoption is going to
shoot up, or people are going to be suddenly super impressed by a 1.0
release. Adoption is still going to be driven by research needs and
documentation, not by what we're calling it or the fact that it's version
1.0.
True. I wasn't trying to imply that a 1.0 release itself would shoot up
adoption, rather that projects in the pipeline will. Depends on the
timeline of those projects, of course.

My counter proposal is to roll out 1.x under the khmer name, and make it a
stable and good codebase. Then, when early 2.0 work begins, fork the
repository over to a new name and document it appropriately. Since I expect
2.0 to swizzle around the script names and API, it's a fine time to make a
break with the 'khmer' name. This would be in ~1 yr, presumably.
Makes sense.

And, for the papers (hopefully) coming out soon, we're not going to be
changing
the name in anything that's already mostly written, regardless of what we
decide.
:%s/khmer/NEWNAME/gc? ;)

I just don't see a strong reason to hurry, and I am against doing things
fast (or at least without long thought) largely on principle, which stems
from being an old fart with lots of experience... things done at the last
minute are typically done poorly.
All fair.

I'm not really sure it's that urgent it be changed, although before
someone complains is always better than after. Obviously, the repo and the
software itself hardly scratches the surface; the online presence and
hard-drive flotsam is the biggest obstacle. I know from experience that
finding every instance of a name is an easy task to underestimate...

Proposal: shoot for pre-NGS workshop this summer, with a 2.0. If rolling
out new versions is actually going to be as easy as has been touted,
another major version isn't that big a deal. It gets it out a little sooner
than a year from now, but gives more time than a few weeks to consider
side-effects. Most it importantly, it would be changed before one of our
major outreach events. Is it safe to say that the NGS workshops have
contributed significantly to khmer's adoption thus far?

[ctb]

On Wed, Mar 12, 2014 at 07:16:12PM -0700, Camille Scott wrote:

I'm not really sure it's that urgent it be changed, although before
someone complains is always better than after. Obviously, the repo and the
software itself hardly scratches the surface; the online presence and
hard-drive flotsam is the biggest obstacle. I know from experience that
finding every instance of a name is an easy task to underestimate...

I think that is a good point that actually argues for making the new name for a
substantial new version, in the sense of being a clean break from old
scripts/APIs. We don't have to change our current online presence; khmer can
point to khmer v1.0, and then oxli (or whatever) can point to "khmer v2.0".

Proposal: shoot for pre-NGS workshop this summer, with a 2.0. If rolling
out new versions is actually going to be as easy as has been touted,
another major version isn't that big a deal. It gets it out a little sooner
than a year from now, but gives more time than a few weeks to consider
side-effects. Most it importantly, it would be changed before one of our
major outreach events. Is it safe to say that the NGS workshops have
contributed significantly to khmer's adoption thus far?

I don't think the NGS course has had much to do with it. I think
basic "effectiveness" and blogging/Twitter have been the main drivers.
But no evidence.

[camillescott]

My intuition was that the people flowing through the workshop are given direct exposure to the software and are really hammered with its benefits (indeed, they may even start to think of it as necessary, depending on how much prior experience they had); they then spread the word through their labs, who are reminded and keep up to date with us through social media. [synergy, maaaaan.]

'course, no evidence on my end either.

[RamRS]

I offer my testimony to the effect of NGS workshop. A collaborator attended
it and introduced me to Titus/khmer.

Ram

On Wed, Mar 12, 2014 at 10:35 PM, Camille Scott notifications@github.comwrote:

My intuition was that the people flowing through the workshop are given
direct exposure to the software and are really hammered with its benefits
(indeed, they may even start to think of it as necessary, depending on how
much prior experience they had); they then spread the word through their
labs, who are reminded and keep up to date with us through social media.
[synergy, maaaaan.]

'course, no evidence on my end either.

Reply to this email directly or view it on GitHubhttps://github.com//issues/320#issuecomment-37493861
.

[kbradnam]

The weakness of your initial list is that there is no direct — or indirect for that matter — connection to kmers. Some suggestions I mentioned to Titus on twitter today:

• OmniKmer
• Kmermatic
• SpecialKmer
• The Kmerator
• Kmer+
• Kaymer
• Okaymer
• OKmer
• ChucKMERNorris ;-)
• TKA - Total Kmer Analysis
• KTK - Kmer Tool Kit
• ATK - All Things Kmer
• KAT - Kmer Analysis Tools/Toolkit

The letter K is a letter that is very visually distinct. It is also your most obvious hook that relates to kmers. I strongly suggest that you keep a name that strongly features the letter 'K'.

[qingpeng]

FYI
Below is the list of known k-mer counting tools.

BFCounter DSKJellyfishKAnalyze KhmerKMC MSPKmerCounterTallymer Turtle

On Sat, Jun 14, 2014 at 2:18 PM, Keith Bradnam notifications@github.com
wrote:

The weakness of your initial list is that there is no direct — or indirect
for that matter — connection to kmers. Some suggestions I mentioned to
Titus on twitter today:

• OmniKmer
• Kmermatic
• SpecialKmer
• The Kmerator
• Kmer+
• Kaymer
• Okaymer
• OKmer
• ChucKMERNorris ;-)
• TKA - TotalKmerAnalysis
• KTK - KmerToolKit
• ATK - All Things Kmer
• KAT - Kmer Analysis Tools/Toolkit

The letter K is a letter that is very visually distinct. It is also your
most obvious hook that relates to kmers. I strongly suggest that you keep a
name that strongly features the letter 'K'.

—
Reply to this email directly or view it on GitHub
#320 (comment).

[kbradnam]

I appreciate that renaming software can be seen as a big risk when people are just starting to become familiar with the initial name. My suggestion to deal with this would be to ensure that maybe for one entire year, you always use the new name in conjunction with a subheading/subtitle that lists the old name. E.g.

All Things Kmer (ATK)

The new name for khmer

Or even…

All Things Kmer (ATK)

The Kmer-analysis tool formally known as khmer

If everyone is consistent in how they do this, and you ensured that you always did this, it would reduce confusion in the 'transition period'.

[mr-c]

@kbradnam Thanks for the feedback. Yep, our (unwritten until now) plan was for at least a year of using the old name in conjunction with the new name.

[blahah]

How about 'wisenkmer'?

[mr-c]

Heh. I think we are settled on 'Oxli'.