Closed choldgraf closed 2 years ago
I suggest jupyter over nb, since it isn't notebook specific. I think nb
comes from the days when most notebook and notebook server extensions started with that.
schwag, because it is usually a bag of stuff passed to you just when you're getting started at some event. Not really serious though. :)
I vote for Doug
(good point about not being notebook specific, I believe @manics brought up the same point)
If not Doug, then:
what about jupyter-content-puller
? I like jupyter-data-puller
but worry it will give people misconceptions about the workflow that this tool was designed for (which is distributing content to hub users). I feel like we generally recommend other workflows for pulling in data into Jupyter than this
jupyter-content-puller
is a good one. I think of nbgitpuller primarily by what it does (pulling) rather than its purpose (pushing, distributing) but maybe that's not how it should be named.
jupyter-payload-puller
invokes jupyter's spacey theme.
Suggesting names is fun.
I think nbgitpuller is like... the 4th or 5th name for this project? It's gone through a lot of renames, but nbgitpuller is the one that has stuck the most. More importantly is the idea of an 'nbgitpuller link', and changing names here would require re-education of that too - people would have to remember that 'oh, it is a jupyter-content-puller link, but that is the same as this nbgitpuller thing'. data8 still calls them 'interact links' (interact is a former name), and that's still confusing. So I want to say that renaming has fairly high costs.
/cc @ericvd-ucb, who has experience explaining nbgitpuller links to lots of users. Would a rename be confusing?
Internally, we still use git and there's a core feature we provide that relies on that - the merging of pulled content with what's locally there.
My intuition is to avoid yet another rename...
Names it has had so far (I'm looking at history of setup.py
for this):
6b56b46a381f157d5f720fbec07bb070e5e7507f was when the nbgitpuller name was adopted.
I agree that renaming is a disruptive change. I guess the question is whether we think the current name is misleading enough to new users that it justifies changing and disrupting the workflows of existing users. It's hard for me to know the answer there without doing some user research :-/ .
There were a lot of nodding heads when we discussed this in the team meeting, which is why I opened this. But if people in general don't feel very strongly that we should rename, I don't think we should push it.
Does anybody want to vote in favor of "we should change the name now"?
Note that even though we pull from ZIP files etc, we still use git in the update process. If you pull a zip file twice, files are updated like if it was a new HEAD in a git branch -- I think.
So, if we remove git entirely, we should be clear that it has a big role no matter what.
I'd love to hear from @ericvd-ucb, as he's a lot of experience with evangelizing this.
Hi - Im not sure I have much novel to contribute -
JupyterContentPuller
is a step towards a clearer name that conveys more than it confusesThinking back on this, it feels like we are in this situation:
nbgitpuller
isn't the greatest name, but it's not that bad eithernbgitpuller
for several months now, and changing it would be disruptiveTo that extent, I feel like we should just leave the name as-is, and focus our efforts on improving the use-case documentation via things like https://github.com/jupyterhub/nbgitpuller/issues/236 . Do others agree or object?
I agree on leaving it as it is currently, because I feel no name is a great fit anyhow, and the extended functionality we may adjust to is optional rather than built in.
I'm going to close this as 'let us not change it'. Thanks for the discussion everyone!
Proposed change
Now that we are introducing a lot of nice new flexibility for this tool (see #194 ), we might consider renaming it to be more descriptive. The name nbgitpuller will make people assume that we only pull
git
artifacts, whereas we can now do more than this!Benefit
The main reason for doing this is to make it easier for potential users and developers to understand the scope of this project. By removing the explicit call-out to
git
, people might more quickly imagine using this tool for more workflows like Google Drive and Dropbox pulling.(Optional): Suggest a solution
A few options that were thrown around in a recent meeting (some more serious than others)