sorry, 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.
Just 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.
if 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?
if she was editing the wrong files, the answer is to do a little more research before diving in.