search

greenelab / covid19-review

A collaborative review of the emerging COVID-19 literature. Join the chat here:
https://gitter.im/covid19-review/community
Other
116 stars 81 forks source link

Managing checklist in New Paper Templates #78

Open rando2 opened 4 years ago

rando2 commented 4 years ago

@LucyMcGowan and @SiminaB had been discussing the value of having a checklist where someone submitting a paper summary can confirm which sections they filled out vs skipped.

@LucyMcGowan implemented a prototype here

My only concern is related to implementation, specifically formatting the check boxes correct so that they will work when copy and pasted. I believe the issue templates open in plain text (so the check boxes look like - [ ]; however, once the issue is submitted, the check boxes will be visible as interactive boxes:

If I copy the "test box" lines above from Preview mode (translated markdown), here's how they look: test box 1 test box 2

But if we use the code formatting like I did for the inline example ( `- [ ] `) then they won't work when copied from plain text!

This seems kind of trivial but I'm not sure how to work around it from a usability standpoint, since in many cases, the paper submitter is likely to copy the check boxes out of the plain text template (so they will work), but all subsequent commenters will copy them out of the issue and lose the formatting.

LucyMcGowan commented 4 years ago

I was not intending for anyone to copy the check boxes, they should ideally just stay in the first issue comment (so that new people looking at the issue can easily see what has already been completed without have to read the entire thread)

rando2 commented 4 years ago

Ah! Perfect. I'll close this issue then, sorry I misunderstood!

rando2 commented 4 years ago

Update: We are having an issue where people need Write, Maintain, or Admin to edit checkboxes that another user set up (so if someone else submits the initial comment, and then a second person adds new sections, they aren't able to update the checklist).

Problem 1: We can't really give out write permissions too generously because GitHub is very new for most collaborators. Currently, the people who have write, maintain, or admin are: @LucyMcGowan @SiminaB @rdvelazquez @agitter @mprobson @cbrueffer @cgreene and myself (and also Daniel Himmelstein, but he's here exclusively for Manubot so I won't even tag him). There are several grad students I am planning to give write permissions once they get a little more experience with GitHub, but, right now, I'm not sure we would have the critical mass to manually check boxes on each paper review.

Problem 2: (caught by @rdvelazquez ) Even if we get the checkboxes to work somehow, they will not really reflect the status of completion because we use checkboxes to manage label assignment.

Proposed solution (from @SiminaB ): Add a tag for "Initial review completed" (or something similar)

Possible problem: People need triage permission to assign labels to issue. I am less worried about granting these permissions (which will be time consuming to get started but should be OK to maintain unless we see another explosion of new interest), but I'm not sure how to force people to accept them.

Proposed solution: Perhaps someone could screenshot how you accept new permissions assigned to you and add it somewhere in the documentation (probably CONTRIBUTING.md)? Then we can comment on issues from new contributors encouraging them to accept the permissions so that they can add tags to their own paper issues. I can't take these screenshots because I'm an administrator on this repository and can't revoke my own permissions to go through the process of accepting them!