Hey, so I was thinking about yupferris/rustendo64#15, yupferris/rustendo64#20, and yupferris/rustendo64#21, and I'm starting to get the feeling that these contributions might be becoming a bit too significant if that makes any sense. The main point of this project was to document all of the thought processes and resources that went into everything, and the unfortunate part of accepting certain PR's is that we lose quite a lot of that for significant amounts of code that I can't go over on the stream. So, while I certainly appreciate the contributions (they've been great so far), and I'm super stoked you guys are excited about and interested in the project, part of me is a bit on the fence in terms of accepting these.
I can also understand that I hadn't really set a precedent for what I would/wouldn't accept early enough in the project; to be honest I didn't really anticipate receiving any contributions for quite some time. This whole thing has started moving pretty fast!
I've written more of my thoughts in the readme's contribution section, so that moving forward everyone has the right expectations (including myself) for what makes a good PR that aligns with the project's main goal, which is to get everything documented on stream: https://github.com/yupferris/rustendo64#contribution-please-read-before-submitting-a-pr. Of course, I'm open to a bit of discussion on this still, but I at least wanted to get that in the readme quickly.
Anyways, here are some thoughts I have on the specific PR's I mentioned:
A few things on this one - first of all, this is really cool! Second, this was proposed as a gist originally basically for the reasons I'm writing this gist now :) Good job thinking ahead more than I had about this potentially being an issue and bringing it up that way first! I think now that I've thought more about what kind of contributions I want for the project this PR doesn't really fit; however, now that we've got a PR ready, you've done a significant amount of work on it, and I rejected yupferris/rustendo64#14 in favor of it (which I feel kinda bad about already) I think I should still accept this. Would love to hear your thoughts on it, @birkenfeld.
Another good contribution! I hadn't heard of Clap before and it looks really cool. For this one, though, I think I'd prefer not to accept it, purely for the fact that I want to code this on the stream. I'm thinking had this been considered post-this-gist, a github issue would've been the most appropriate way to make this contribution.
While this is really helpful, I think it's a perfect example of a contribution that takes away from the stream - while building this table might be pretty boring on the stream, I think it'd be cooler to do it live than accepting this PR. The primary reason for this is many viewers have already mentioned they don't know where to begin with various doc's etc, how to convert them to meaningful code, etc., and this process would be very helpful for them. So, again, great contribution and code, but I think the project will benefit more from doing this work on the stream.
Thanks again guys and sorry if this seems kinda sudden; I should've tried to set some kind of precedent earlier on. Please let me know your thoughts!
IMO: Not accepting certain PRs (mainly crates) makes this a dream for novice Rust programmers. We'll get a taste of how you implemented $THING, instead of "Simply import $THING". Possibly later down the line it would be wise to use more crates for some functionalities, but I personally enjoy that you're not currently using them for much.
Keep up the great work!