Help with maintenance

[jennybc]

Hello @SamanthaToet @amysheep

I'm glad to hear you'd like to join in the fun here!

I propose this as a good way to start:

• You pick one (or many!) PRs and look them over and make a comment to the effect of LGTM ("looks good to me") or an indication of what might be problematic. I watch this repo, so I'll be notified of this.

Feel free to ask me questions. I assume this will evolve to giving you push permission and you could merge things yourselves.

There's probably other stuff missing here, such running the tests anywhere like travis. So there's also scope to make some improvements to bingo vs. just merging cards.

[amysheep]

Cant wait to make some fun happening!

[SamanthaToet]

This sounds great! Diving in now.

[jennybc]

More ideas for possible contributions beyond approving cards:

Guidelines for submitting a new card. For example, I think there is some minimum number of lines that are necessary to work at all and to work "well". We need to spell that out somewhere, such as a CONTRIBUTING file. It could eventually also be something that is tested, so that incoming PRs with too few entries are flagged.

I haven't looked at this for a long time. I now wonder why the card data is stored as .R files, with c("a", "b") syntax, as opposed to to plain text files with one entry per line. Current Jenny thinks the latter seems much more sensible. Unless anyone can discover a reason for this peculiar past decision, it would be nice to switch over.

[SamanthaToet]

That's a great idea. I could try expanding on the CONTRIBUTING file so that's it's more of a "how to." Maybe we could also add something to the README? Down the line I think a test counting the number of lines would be really helpful. Actually, that doesn't need to be too far down the line... I can play around with that too.

[amysheep]

I can look into why the card data is stored as .R files.

[jennybc]

That's a great idea. I could try expanding on the CONTRIBUTING file so that's it's more of a "how to."

Oh, there is already a CONTRIBUTING file! Yay. From my experience, people don't really read these and especially not if they are long. So this not a "more is more" situation. Your idea to mention the key fact about "# of squares" in the README is good. We should probably do that and call it a day.

[jennybc]

To be clear, I think the test re: number of squares is still worth doing.

[amysheep]

I thought the number of squares per card is always 5 i.e. 5*5 per card.
We can add test for the length of the topic list though. Maybe a minimum of 28?

[amysheep]

@jennybc Are we requesting .R for submission or other formats are fine (e.g. .Rmd, .pdf...)?

[amysheep]

Also, FREE is auto generated and not required to be in the c() list right? @jennybc

[jennybc]

Are we requesting .R for submission

Yeah that's how this is currently setup.

Also, FREE is auto generated and not required to be in the c() list right?

I sure think so.

From double-checking some PRs, it's clear we need a test that would identify submissions that are just structurally wrong. I think almost 50% of the current batch would break the package.

[jennybc]

Hi @pjmathews here's where we're getting thing going re: help with reviewing PRs (in the immediate sense, which is still much needed) and outlining some package enhancements that would make it much easier to check if PRs are structurally OK (for future and for building more package dev skills).

[pjmathews]

Thanks Jenny. Looking at this now.

[amysheep]

i'm going to make some tests for

• test topic .R file structure (is it a vector? is it a .R file)
• Capitalize the first letter?
• FREE shouldn't be in the list