4 ms·
"So where did I go wrong?" hard to say without seeing the pull requests, but if you edit compiled code and call it a typo you're probably at risk of doing a lo
by catshirt 15y ago
"So where did I go wrong?"
hard to say without seeing the pull requests, but if you edit compiled code and call it a typo you're probably at risk of doing a lot of things wrong.
perhaps you just need to spend a little more time learning about a project before trying to push your changes. seems like all of the issues presented in the comic could have been avoided by paying more careful attention.
- yummyfajitas 15y agohard to say without seeing the pull requests, but if you edit compiled code and call it a typo you're probably at risk of doing a lot of things wrong. True - what you should do is submit a fix that takes compiled code out of the repo and replaces it with a build script.
- technoweenie 15y agoThat's definitely a change I'd bring up with the project first. I agree that having compiled code in there is bad, but it's typically not something a first time pull requester touches. Same goes for project files (Gemfiles, package.json, licenses, changelogs, whatever).
- devth 15y agoMaybe she was referring to generated or combined code (common in JS projects).
- catshirt 15y agosorry, what distinction are you drawing between "generated" and "compiled"? even "combined", for all intents and purposes, doesn't discredit the point: if she was editing the wrong files, the answer is to do a little more research before diving in.
- megamark16 15y agoJust an example from my experience; if you're using lesscss and you're committing the generated css files to source control, someone cloning your repo and trying to fix a UI bug would probably just jump into the css file and make the change. They may not know that those files are generated by the .less files.
- catshirt 15y agomegamark16: the answer then, for the third time, is to take a second to learn the system before you try and fix it.
- nknight 15y agoWhen did it become accepted practice to check in generated code? That's what packaged downloads are for.
- cygx 15y agoif she was editing the wrong files, the answer is to do a little more research before diving in. That's not always as easy as it sounds if a codebase is large, uses non-standard build environments, violates best practices (like unnecessarily checking in generated files, and, if it's really necessary to do so, not making obvious that it's a generated file -- assuming it wasn't a simple oversight on Rachel's part), ... In my opinion, pull requests should be submitted even if you're not sure they're exactly right as long as you've done a reasonable effort to make it so: After all, familiarizing yourself with a codebase is done by working with it, and asking for help when you're stuck -- and that's exactly what a pull request is: a request for comments, where you show others what you've done so far. Of course you could have used the mailing list instead, but if there's this nice site available where you can publish your code, which keeps track of changes and provides a commenting and message system, why not make use of it?
- yonran 15y agoEvery time I have tried to jump into a project, it has required a couple hours to figure out the compilation method, unit test runner, peculiar inheritance structure, or messy class names. This is simple stuff that the author left out of the Readme because he wasn’t expecting contributions. So I woudn’t blame the contributor if she didn’t fully understand it before the pull request.