Cooperative document creation workflow

Hi,

I am struggling with my specific workflow as usual, and not sure whether going through Classroom is our best option. In short, our next group assignment in class will be the cooperative creation of a document, in which each group will write one section (in one or more files), then students will revise content written by others, and we will finally gather it all in a single final document that contains all the sections, which I was thinking then to get through to something like GitBook so that they can get a “document format” type of thing (which does not export to PDF in the new version, so I am reconsidering this last step as well).

My initial thought was to create the group assignment in Classroom and add the basic structure as stater code with instructions on how to create their documents, what to name them etc. (oriented at creating the “final book” later on). Groups would work in their own repos, adding commits etc, second step they would fork and contribute to repos by other groups, add pull requests and merge… but THEN, when we are done with creating the content, their group repos would NOT be forks of my starter code repo, so… how would I merge back everything into one single repository?

So what I’m thinking now is, skip Classroom completely, create my starter code repo and have students fork that. Then their group repos would act as forks of my central one and we could create pull requests from each group repo/fork to the central one, and finish with one, cooperatively created, repository for the whole class.

This gets me thinking that I never seem to come up with a workflow that fits inside GitHub Classroom… Am I missing something? Is there no point in trying to use Classroom for the workflow I’ve described, and “manual forks” are actually a better way…?

Thanks for reading! I hope I can get ideas on this…

Miren

2 Likes

Hi, I have something very similar in my class. I share a bookdown project with my students outside of github classroom. The will work in separate branches and have to create pull requests to contribute back --> see here https://github.com/mschermann/data_viz_reader

2 Likes

Mmmh, interesting. So instead of forking, working on their own repos, and then merging back, your students will contribute to the same repo all the time except to specific branches, if I got it right. It may be helpful to remove that additional layer of forking for them, maybe it makes everything just simpler to work with (and to manage).

My only objection is, we are not using R at all, so will have to check whether bookdown is an option. Gitbook used to be great but have removed the PDF export functionality in their last update, so…! :woman_shrugging:t2: You got me thinking!

I also liked the idea of the code of conduct. Thanks for sharing!

1 Like

I so wanted to do this for our Publishing students to work on a book collaboratively. In the end though, Git didn’t seem to fit for us, so we used Penflip (search on Google) - this uses Git as a bespoke setup.

We tried other systems and I had hopes for the WIKI inside GitHub.
Penflip did the trick but not very reliable. I tried Prose, GitBook and others but OmniBook looks promising.

I wrote a paper about Iterative Publishing which mentions these trials. Online version here: https://publisha.github.io/papers/iterativepublishing/

There are other ways to collaborate on texts and if anyone has experience of using GitHub Classroom in this way, I would love to hear about it.

3 Likes

We did something similar during the course 2016/2017 with Computer Science students. We followed the methodology you proposed:

create my starter code repo and have students fork that. Then their group repos would act as forks of my central one and we could create pull requests from each group repo/fork to the central one, and finish with one, cooperatively created, repository for the whole class

The repo is here ULL-ESIT-SYTW-1617/presentaciones-todos. It is deployed in GitHub pages

The workflow the students used is described (in Spanish) here:

It follows the methodology described by GitHub people in section Working with Forks from Collaborating with issues and pull requests

  1. https://help.github.com/articles/configuring-a-remote-for-a-fork/
  2. https://help.github.com/articles/syncing-a-fork/
2 Likes

Bookdown is really easy. It took my students a week to get used to it. Since it is just text, handling conflicts is very easy. My hope is that at the end, we have a nice reader that is useful beyond the course. Let me know how your project works.