Comments (15)
So, I don't know that tracking is 100% needed; some people will end up starting it some other way, so we will know many, but not all of the people who are writing papers - but also many of the people who fork will never actually get around to submitting.
Looking over here: https://stackoverflow.com/questions/6286571/are-git-forks-actually-git-clones
Forks are just clones with some extra database connections. For a clone, vs a fork, then "When you clone a GitHub repo on your local workstation, you cannot contribute back to the upstream repo unless you are explicitly declared as "contributor". That's because your clone is a separate instance of that project."
I don't know that we actually want most people contributing BACK to the templates (unless they are actually contributing to the templates, that's a different category).
But it's subtle, so perhaps I'm taking the wrong slant.
from article_templates.
I guess my take is that the model I learned first/which is most obvious to me is:
a) Clone if you're part of the project and will want to change it
b) Fork if you're not and are going to be diverging
So I was just thinking that if we ask (Github-aware) people to clone it rather than fork it we would explain why, whereas forking would be clear. For the people who don't know what either means, it doesn't matter.
But if fundamentally they are the same this is no big deal.
from article_templates.
I guess my understanding is the other direction: a fork maintains connections in github, so it's useful if you want to contribute back. a clone is bare, so is best when you will be doing something different!
from article_templates.
@mrshirts -- I think there is a very important operational difference/difficulty:
- With your procedure (as per your documents) they actually have to create a new repository by moving the files into it. Perhaps this is fine, but it adds extra steps, and requires them moving all of the files they need over, so they will often forget things we would like them to have (the license, etc.).
- With my procedure (forking) they already have a new repository and can just start working on it, and have to REMOVE files they don't want.
Perhaps @jchodera has other thoughts on which approach is better.
from article_templates.
(Also, a clone is not bare unless you do special invocations, it seems: https://help.github.com/articles/duplicating-a-repository/ ). I think basically a fork is a clone that is "free" from the original (though still connected for tracking purposes) so it can be extended/modified even if you don't have write permission to the original, whereas a clone is still tied directly to the original so you can't make server-side updates unless you get permission.
In other words, a fork is a special type of clone that people often need because they don't have write permission to the original.
Your procedure, I think, is just using a clone to create a new fresh repo from scratch.
from article_templates.
I thought about this some more and also started creating my own repo for a paper, and realized that you're right, Michael. It'll be simpler for them if they are creating their own from scratch and putting in the files they need. We should probably just make sure to put in a careful list of exactly everything to put in. :)
from article_templates.
Are you sure that's easier than forking a repo with an prebuilt structure? It seems like it would be much better to have a template best practices paper with the repo organized how we like, README.md
files structures as we hope, and manuscript template in the appropriate style. Overleaf does this for their manuscript templates, and it seems to work really well.
I think asking everyone to pull in files manually is just asking for trouble and encouraging heterogeneity.
from article_templates.
Yeah, I guess both have their pros and cons. If they fork, then they have the commit history, etc., from this repo, plus they have to clean out files they don't need, change the repo name, change the description, etc., which is a bit of work, but at least they'll have all of the right files. But if they create a new repo they have to copy IN all of the right files and set it up properly. Neither of these is idiot-proof...
from article_templates.
from article_templates.
I was talking to @dgasmith this evening, who suggested that cookiecutter may be the right solution for this problem.
from article_templates.
I'll nominate john to figure out how that would work (after the conference, of course!)
from article_templates.
@dgasmilth now suggest mirrors:
https://help.github.com/articles/duplicating-a-repository/
from article_templates.
One issue I keep forgetting about is this: What instructions do we give them so that they have a new, independent repository that they can push, pull, and fetch from without dealing with the original? I should try this for mirrors. Ideally you'd want it to be totally separate/disconnected from the original at this point.
from article_templates.
from article_templates.
OK, that's perfect, then.
@mrshirts - should we mark this as resolved and just update the docs to tell people to mirror?
from article_templates.
Related Issues (20)
- Section / subsection titles intruding into gutter and margins HOT 9
- Number references by order of appearance HOT 4
- Reference standards for bibliography. HOT 26
- Formatting at time of publication (DOI, volume, etc.)? HOT 14
- Templates producing weird 'fi' characters? HOT 6
- How to include version number in the title of articles HOT 14
- Reference formatting: should pMID's be in the references? HOT 5
- Bolding of Editor names, no author names HOT 2
- Posting DOI's properly in articles and on website HOT 10
- Can we figure out how to make white-spacing easier? HOT 1
- List of things to fix/adjust before issue 1 published (we will ask for people to redo the templates then). HOT 23
- Issue number HOT 9
- Force people to include licensing terms by including it in the template? HOT 32
- Create a way to add translators to the article? HOT 3
- Template had old name for software analyses section HOT 1
- Switch from `natbib` to `biblatex` in `livecoms` document class HOT 12
- Consider using Github's "template repository" mechanism
- Bibliography Modernization HOT 4
- Fix display long URLs in GitHub link HOT 1
- Consider adding line numbers to review versions?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from article_templates.