What should we call our new genetics toolkit?

[hammer]

We would like to get our genetics toolkit prototype into its own repository soon, for many reasons.

Now is a good time to ask the questions: what should we name this repository, and under which organization should we put it?

My proposal is that we put our work into scikit-allel/scikit-allel soon. Another option would be to put our work into scikit-statgen/scikit-statgen or related-sciences/scikit-statgen.

I've put some thoughts below for these options. I'd love to hear what others think soon, especially @alimanfoo.

Org

Org option #1: scikit-allel

Our goal has been to work with @alimanfoo to converge our approach with his so that we can ultimately contribute our code to the https://github.com/scikit-allel organization.

Org option #2: scikit-statgen

See below for a more detailed discussion.

Org option #3: related-sciences

In the short term, it may make sense to put this into a repo or set of repos in our related-sciences organization, though we'd like to make this toolkit be as independent and multi-contributor as possible from the start, so this path is not preferred.

Repo

Repo name option #1: scikit-allel

scikit-allel pros

• Alistair has put tremendous effort into the original scikit-allel repo, and has created a home for future work at https://github.com/scikit-allel. If he intends for new work to go there, we should put new work there!
• The 176 stargazers on the cggh/scikit-allel repo will naturally be interested in what's happening under the scikit-allel organization.
• The scikit-allel name associates this work with other scikits, which makes the project feel independent of a single sponsor.
• The term "allele" nicely captures that the goal of this toolkit is to work with genetic variation data, not read-level sequencing data, for example (cf. Allen Goodman's scikit-genome).
• This repo name is not taken under the scikit-allel org.

scikit-allel cons

• The new toolkit is likely to be sufficiently different from the previous one that having the same name may cause confusion for users. If we do plan to keep the name, we should discuss what commitment to transitioning users from the old toolkit to the new one we want to make.
• Every time I mention the package name to someone, they ask me how to pronounce it, and why there's no "e".
• The word "allele" is one of the more confusing terms to explain to software developers new to genetics. For example, see the "Two different meanings of allele" section on the Wikipedia talk page for "Allele".
• An argument against the scikit-* naming convention in general: it's unfortunate that the Python module name is different from the repo name. Note that Alistair has actually used skallel as the repo name for scikit-allel v2, which is non-standard (cf. scikit-learn, scikit-image, scikit-genome). Given the popularity of scikit-learn, the user community has largely been educated on this topic. It's still a small speedbump for new users though.

Repo name option #2: scikit-statgen

I believe the scikit-allel name should be the default option, and we will need to have a very good reason to use a different name. I'd like to propose scikit-statgen as an alternative for the purpose of having an example to drive the discussion forward. If we choose this name, we'd of course have to update the org name as well.

scikit-statgen pros

• "Statistical genetics" is a field of inquiry recognized by many. For example, Ben Neale lists it as his first area of interest on Google Scholar.
• "statgen" is a common abbreviation of statistical genetics. For example, the University of Michigan's Center for Statistical Genetics uses the statgen org name on GitHub.
• There are no pronunciation issues.
• It gives users a better idea of the functionality to expect in the library, I believe, though others may disagree.

scikit-statgen cons

• It's longer.
• It's different from scikit-allel, so loses some community awareness, and the clear tie to Alistair's prior work.

[hammer]

Some notes from our discussion of this topic on the 2020-06-11 call

• AM likes "statgen"; broad, but not too broad (cf. http://scikit-bio.org)
• AM notes that "scikit-" is an old thing now, tied to SciPy
• Perhaps use "pydata-statgen" as the organization, "statgen" as the package?
  • "statgen" is a strong name; cf. Hugging Face blowback for "nlp"
  • JH thought: pydata-statgen/sgkit?
  • JH concern: NumFOCUS has the PyData trademark
  • JH emailed Leah Silen, NumFOCUS executive director, to inquire about the use of pydata-statgen as our organization name.
• AM wishes skallel could be broken into multiple packages
  • Want 100% test coverage on core methods
  • Still want everything in a single namespace
  • AM: Arrow is too much
  • TW: Avro was hard, but things get abandoned
  • AM: it's nice to have a place for grad students to implement a novel method but not have to commit to maintaining something
  • JH: well-defined extensibility interfaces + API annotations
  • TW notes dependencies as another distinction between core and peripheral

[hammer]

@alimanfoo, @jeromekelleher: what do y'all think about sgkit as the package name?

Also, some contingency planning in the likely case that we cannot use pydata- as a prefix in the org name.

• scikit-statgen/scikit-statgen
• sgkit/sgkit
• pystatgen/sgkit
• pystatgen/pystatgen
• pystatgen/statgen

[hammer]

(Posted by @tomwhite)

I like statgen, though perhaps pystatgen would be better by emphasising the PyData angle. I think pystatgen is better than sgkit for that reason, also sg is a bit obscure.

Another approach to naming is to invent words. As Doug Cutting said, when asked why he chose the name "Hadoop":

The name my kid gave a stuffed yellow elephant. Short, relatively easy to spell and pronounce, meaningless, and not used elsewhere: those are my naming criteria. Kids are good at generating such. Googol is a kid's term.

New words like this don't seem particularly common in the PyData ecosystem (and I don't have any suggestions of any for this project). Portmanteaus like blosc, xarray, jupyter seem to crop up more in PyData, and are more in line with the suggestions from Jeff.

Another option is to appropriate commonly used words: pandas, hail, glow - but these can be hard to Google, so you'd inevitably have to add a qualifier like python or statgen anyway.

[hammer]

(Posted by @jeromekelleher)

I really like pystatgen as the org name. That seems like a reasonable summary of the community that we hope to build, without seeming like a "land grab". It's concise and descriptive, and I can imagine a number of different packages developing under that umbrella.

I also like sgkit as the package name. It's concise, has a fairly small number of Google hits, it's free on PyPI and it's not in the Urban Dictionary. It conveys the idea of a toolkit providing a core set of fundamental operations for statistical genetics.

In isolation, I think I prefer the package name statgen but I agree that it's probably setting the wrong tone (and wrong expectations) to have a package that purports to encompass the entire field.

So, I vote for pystatgen/sgkit.

[hammer]

Okay, by my tally we have votes for:

• sgkit/sgkit: @eczech (in Slack)
• pystatgen/sgkit: @jeromekelleher
• pystatgen/pystatgen: @tomwhite (if I've interpreted your message correctly).

@alimanfoo what's your vote?

[hammer]

Leah Silen from NumFOCUS got back to me about using pydata-statgen as our organization. She says we are the first ones to ask, and that she will let me know by the end of next week!

Thanks for reaching out about the use of pydata. We're working to finalize our trademark and usage guidelines so accessing this information will be much easier in the future.

PyData represents multiple groups including global events and meetups, the collective Python data science stack (some of which use the pydata.org domain), and the broader Python data science community. Because of this, we want to avoid any confusion or the appearance of something being sanctioned as the official PyData podcast, project, company, etc.. That said, this is our first request for using PyData in a project name. Let me discuss it with the rest of the board and get back to you with an answer. I should be able to let you know something by the first part of next week.

[hammer]

Okay I think we have emerging consensus around sgkit as the repo name and either pystatgen or pydata-statgen (if it's available) as the organization name. @alimanfoo any concerns with sgkit for the repo name?

[hammer]

(Posted by @alimanfoo)

Hi folks,

FWIW I'm happy to go with sgkit for the repo (and package) name. There is a nice symmetry with tskit which is an important sister project, emphasizing the links between the two is a good thing.

We can always change our minds later if someone comes up with something really marketable :slight_smile:

Cheers,
Alistair

P.S., you might enjoy to know that the precursor to scikit-allel was a package that I named "anhima". I can't even remember how I chose that name, but I was looking for something catchy and unusual. Also known as the horned screamer, it's a South American bird.

[hammer]

Thanks everyone! https://github.com/pystatgen/sgkit is now alive. If we get permission from Leah, I will change the name to pydata-statgen/sgkit.

[hammer]

Update from Leah Silen of NumFOCUS:

Because of our ongoing work to support the growth and sustainability of the PyData community we'd like to see all projects using the PyData name to be a NumFOCUS Affiliated or Sponsored project. This will allow you to join us as a community stakeholder in helping to promote the community while taking ownership and sharing in its benefits. Our Affiliated project criteria are less stringent than those of a sponsored project, you can find application details here.

So, if we want to use the pydata prefix for our org, we need to apply and be approved to be a NumFOCUS Affiliated or Sponsored project.

Some details on the NumFOCUS application:

Project Applications are accepted on a quarterly basis.
Application rounds in 2020 will close on the following dates:

Jan 15, 2020 (Round 1)
April 15, 2020 (Round 2)
July 15, 2020 (Round 3)
October 15, 2020 (Round 4)

Given the project barely exists right now, it's a bit early to apply for the July 15th round. I'll make a note to apply in October!

[hammer]

(Posted by @alimanfoo)

Given the project barely exists right now, it’s a bit early to apply for the July 15th round. I’ll make a note to apply in October!

Sounds good, gives us time to write some code :slight_smile:

In other news, we now have Quansight engaged on the project. We'll have a kickoff meeting with them shortly to go through working arrangements, then we'll connect everyone up.