Track changes (if paper is the focus) or consider alternate project titles?

[mandel01]

I'm responding to the request for comments by @ctb on Twitter. This project is very exciting and I look forward to following it and perhaps contributing. My main comment from reviewing the proposal and issues is, is the paper the focus or not?

The current name of the project (everpub) suggests that it is the focus. If so then more attention could be paid to the publication part. Right now the publication stack is only 1 of 8 focus points. As a scientist who is striving (desperately!) for a more reproducible workflow, a major stumbling block is the inability of git/Github to enable Track Changes-like functionality where individual comments within a PR can be accepted/rejected. I saw the latex package and perhaps something like this would be valuable to work toward. Could have wide-reaching value for git beyond publication as well.

On the other hand, if the paper is not the focus (e.g., https://github.com/betatim/openscienceprize/issues/50) then perhaps the everpub name is misleading? Or is that the point, that the publication and dissemination of results is not connected to the actual "paper"? Anyway, I was thrown here.

[betatim]

Thanks for taking the time to read and leave feedback!

Could you explain the individual comments thing again? My experience of thorough review of work on github is mainly with scikit-learn/scikit-learn. Specific comments on a particular line of a file automatically get closed if a new commit changes that line. This seems to work quite well. Either the comment is specific (change X to Y please), or needs some discussion. If it needs discussing you don't change the line before you arrive at a specific "Ok, we agree to change X to Y". Sometimes comments get auto-closed because of other changes, which is a bit annoying. Is this what you are referring to?

Having said all that, diff'ing and merging of changes is on our radar.

re: name, I think we are going for "publication" to mean much more/broader than the current sense where a publication is a static article published in a journal and nothing else. For me a publication should include: prose for humans, figures, data, code, tables, etc

[mandel01]

Git works well with atomic commits but this is not how most scientists offer changes currently. Here is how a Microsoft Word workflow has worked for a typical paper in my lab. A trainee writes a paper, then a PI offers comments on the entire manuscript. The trainee will accept many (but not all) of the comments and then offer a new version to the PI.

We have stumbled to do this in git when one of the participants is not a git expert. Perhaps the solution is simply better training in git! But offering a solution to accept some changes and not others from a given commit (perhaps, to generate a new commit with only the selected changes?) would be a valuable option and provide a way to improve adoption from folks who are familiar with such a workflow in git.

I think in many groups a busy PI offers many comments at once (hundreds). The case is different from how code changes. I don't know whether it is better to try to change the lab culture, to try to offer technology to bridge the gap, or some combination of the two.

It sounds like this may be less pressing of an issue. Happy to discuss more now and/or after the pending deadline. And happy to advocate for the project if I can be of use.

[betatim]

Thanks for explaining. I will ponder while 😴

[khinsen]

@mandel01 You raise a very good point there. In fact, we have seen this problem right here in preparing the proposal, where at some point we used hypothes.is for comments rather than git-based techniques.

On the other hand, I see this problem as orthogonal to the one we are addressing here, which is the publication of exeutable content. What you suggest would ideally be implemented as a tool on top of git, or as a feature of GitHub. It would benefit many users who don't need executability at all.