Open tracykteal opened 9 years ago
maybe also with just a README in master that points to the gh-pages branch
The one issue I can see with this is that when doing new work I tend to instinctively
git checkout master
git checkout -b feature
git add
git commit
Several times not having a master branch in a SWC repo has caused me to fail early in a way that's saved me some time. That said, if no one else sees this as a problem I'm sure I'll get used to it.
We got rid of the master
branch entirely in our repos for exactly this
reason.
That's a good point. I've gotten hung up on that too. Just the gh-pages branch seems best then.
It just creates an extra step that has to be explained when creating a new lesson, because you have to delete the master branch.
Seeing everyone's feedback, i think gh-pages only is a good idea. my site only has gh-pages. it does keep things simple. going between branches can be confusing if you are less versed w git!
Tracy -- given at some point i'm going to sync our python repo back to datacarpentry, do you want me to try to move towards a guh-pages only repo?
Yes, thanks, let's do that.
I transitioned all lesson repositories (except the *-genomics as I'm not familiar with their current status, and the "original" datacarpentry repository) to a single gh-pages branch. Should I go ahead and do the same for the genomics lessons?
ok - i've transitioned the python-ecology fork in my repo. I'll creat a PR on to the DC repo to update the materials. There is no layout info, YAML, etc in the SQL lessons. Should i fork and add to that repo as well?Then submit a PR? I am just using the basic DC layout. We can formally style it later.
We still need to work on the styling, so yes, coming back for python-ecology is best.
There is no layout info, YAML, etc in the SQL lessons. Should i fork and add to that repo as well?Then submit a PR? I am just using the basic DC layout. We can formally style it later.
This is presumably true for all of our lessons at the moment. I'm happy to take a PR for the SQL, but we should probably also open a super issue to help keep track of doing these updates throughout the full set of organization repositories.
Yes, we need a super issue. Do we also need a template for what all these files will be in each repo? Should we start by creating those files in 'lesson-template' so that we can go through and apply them to each lesson repo?
Should we start by creating those files in 'lesson-template' so that we can go through and apply them to each lesson repo?
+1
Agreed - a lesson template would be best. I implemented the styling just to allow the lessons to be jekyll renderable. But i think they could look much better! And i know there are extra styles we aren't using now. Rather than have everyone go through updating styles, perhaps the lesson template is where we first refine the "look". Then we always apply from there as you suggest. SWC has done some nice styling to their lessons. i know they are using pandoc but you can still use some of the CSS.
Also another side not NOT specific to SQL. I did create the setup instructions as a conditional statement in my workshop. @tracykteal Have you created a workshop template repo as well? The user just puts the language (python or R) in the YAML and the correct setup renders. They are just include files. if this is of interest to you, i can help implement it in the template as well. :)
I used @lwasser lesson template as the model and put it in this repo.
I used the _data/ directory for the files that contain information specific to each lesson, so if the template is updated, it can just be updated throughout and no lesson specific information will need to be changed.
The templating still needs some work, but see what you think.
So should https://github.com/datacarpentry/sql-ecology/pull/18 be resubmitted based on this modified version?
ok sorry i missed this ethan. Actually the sql-ecology that i submitted DID use the template tracy added to this repo BUT i agree we should settle on it first and THEN update throughout. i'll post a new issue specific to this.
no problem. sounds good.
On the discuss list, general consensus seems to be that just having a gh-pages branch for each lesson is best, maybe also with just a README in master that points to the gh-pages branch.
If there are other ideas about lesson repo organization, we can discuss them here and make a decision in the next week or so.