search

sokolhessnerlab / itrackvalr

Toolkit with a built-in pipeline infrastructure to integrate and analyze eye-tracking, behavioral, and self-report data in R.
MIT License
1 stars 0 forks source link

Add "Summary request" issue template #11

Closed aridyckovsky closed 3 years ago

aridyckovsky commented 3 years ago

Please see summery-request.md file for proposed issue template. Ready to merge into main if no changes needed.

aridyckovsky commented 3 years ago

Redoing the issue template using GitHub's built-in issue template designer.

psokolhessner commented 3 years ago

Can't figure out how to ask you to review my commits above @aridyckovsky as the fact that this is your pull request seems to preclude you from being assigned as a reviewer.

psokolhessner commented 3 years ago

c.f. https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review

aridyckovsky commented 3 years ago

@psokolhessner I don't think we can switch roles on a given pull request, but generally, we won't have this dilemma aside from organizational PRs like an issue template (where making the changes automatically authors a PR). We should remove the Answer components from the template, as after thinking about it, we won't have the answers in the issue request, but rather in the committed Rmd/md files that resolve the issue request for summaries.

aridyckovsky commented 3 years ago

Requested a new review with minor changes @psokolhessner. If you approve go ahead and merge and we can consider this resolved.

psokolhessner commented 3 years ago

Hm - answers might be here, right? For example, with participant summaries, this doc would have the whole CSN031 didn't finish b/c of glasses & calibration, CSN### couldn't b/c they withdrew, etc information. And while an Rmd file may have all the models we ran, of course, the summary might focus on summarizing the main/winning model, what it identified, and doing a touch of interpretation on it.

I suppose this may be a bigger conversation about the function of this template - I was anticipating this template might be the final product of a line of scripts/analysis/development that wraps things up in a relatively digestible fashion, in an way that's intermediate between detailed & complex analysis file and a paper. For a use case: summaries are what you could send to involved members of a research team who aren't in the weeds quite as much as you are when you think you're done with a big category of thing, that would be easily digestible/readable, relatively short, conversational, and basically mix implementation/action with interpretation/meaning.

psokolhessner commented 3 years ago

Does this come back to how the original draft identified this as a "summary request template" and I switched it to "summary template"?

aridyckovsky commented 3 years ago

So I think this PR ended up trying to solve two separate problems, as you point out in your last comment.

This template's intended purpose is for a summary request issue, and not to write the summary itself. That's why this template lives within the .github directory, so we can easily request new summaries, sort of like a TODO item. The checklist of questions includes the things we intend for the summary to address.

We should separately have a summary template within the repository's notebooks directory (likely an Rmd that generates md for presentation). Then, when a summary is completed and up for review, we reference the issue that requested it. When the PR that includes that issue is approved and merged, the issue closes, meaning the summary is complete and integrated into the main branch.

psokolhessner commented 3 years ago

Hm, OK, I think I didn't understand how this template would function within the GitHub ecosystem, and though it was more of a template for the summary itself. Thanks for helping clarify that role, @aridyckovsky . Thinking of it like a TODO or a nudge to write an actual summary is a helpful framing.

Will re-edit shortly to reflect that purpose.