lucymcgowan / contributr Goto Github PK

you say

Don't break the package, continuous integration builds should not fail for your Pull request.

may want to give a caveat that PR's may fail and it won't be their fault as PR's don't have access to env vars set by the admin on the repo - e.g. if there's an API key for a web API

I'm pretty sure one day one maintainer will write "beginner" instead of "Beginner" -- could the scraping code account for this?

As we'd been talking about optional maximal duration for the different steps.

• Between a contributor expressing interest and their being assigned to the issue: 1 week?

• Between a contributor being assigned and their first commit in their fork: 2 weeks?

• Between a contributor being assigned and their pull request: 4 weeks?

• Time for answering to any message/pull request (both for the maintainer and the contributor): 4 days?

when I clicked on link to an issue it went directly to it in the same tab - maybe would be better to open a new tab so the contributr app stays open? via like <a href="link" target="_blank">link</a>

maybe there's good reason to not do that though?

• https://github.com/nstrayer/shinyswipr

• https://github.com/MarkEdmondson1234/googleID

• I think all other packages were on CRAN

• It would often end up getting swiped a different way from what I was trying to do - a bit frustrating! Therefore I wonder if you could have up/down/left/right arrows to click as an alternative. This might also be more accessible for people using a screen reader (would need to be tested)

• Also it would be good if somewhere there was a list with the selected issues or maybe even a selected and rejected list, with some way to review and undo decisions before downloading. This is especially important if users won't see the same issue again!

• In general the swiping is a nice way to browse issues, but if this takes off it would also be good to have other ways to search/browse projects. E.g. browsing by package, seaching by keyword.

• Another thing is it would be nice if the package name was highlighted in the description - some issues are very generic and it's hard to know if you're interested if you don't know the package/what it's about!

• Thinking a bit more about the searching this might still be combined with the swiping idea, e.g. filtering the issues that the user sees.

I was wondering if the README should start with something like "contributr is a Shiny app for finding beginner GitHub issues to contribute to. In this README we'll give guidelines for participants in the program, and for potential contributors to the app. Participants are beginners wanting to contribute to repositories, and maintainers of repositories wishing to open issues for and guide beginners" to introduce roles?

maybe a hint about where to click - i think only in the top part works, yes?

RULES FOR MAINTAINERS

• Please respect the guidelines for writing issues.

• Be nice and patient.

• When a volunteer say they are interested, assign them to the issue. (@LucyMcGowan not sure it'd never happen but what would happen if several people wanted to contributed? the first one would be assigned? ) (and do we want to create an Assigned label for making scraping free Beginner issues easier?)

• When the issue get solved, ask the volunteer to add themselves as ctb in DESCRIPTION.

• Be clear about your availability. (e.g. if you usually answer messages within a few days or longer)

• Have fun!

it's a bit small - but maybe that's just me!

• Create a Beginner label whose colour should be #6ABF49

• Time needed for solving the issue is probably too subjective?

• If the issue is urgent, or you would do it yourself if no one does it for a few months, write it down.

• Please write as much context as possible for a newcomer to understand what you mean.

• If you have any other preferred channel of communication about the package than the issue thread itself (e.g. a Slack team), please write it down.

• Optional template

  • Issue title (try to use verbs?)
  • Problem/motivation.
  • Steps (e.g. write new use cases, then add them in a vignette).
  • Dependencies/tools one should know to solve the issue (e.g. if your package includes Rcpp code or R6 classes).
  • Contributor rules if there are some.

since they need a github account anyway to contribute

(the google login works nicely by the way!)

i guess users don't need to login at all, correct? login is just to save state?

Hi Lucy,
I was trying to follow the instructions from the README.md file in the https://github.com/LucyMcGowan/contributr page. i got up to the part, Create a Google API Project,.

I encountered a problem with enabling the API. I couldn't decide which API or service should be enabled.

There's Google Drive API, Google Sheet API, Google Calendar API.... i couldn't find one which links to dropbox. Thanks. Sorry if this is a dumb question.