Generally speaking, MyComponent is for creating and maintaining extras of your own, not other peoples' extras. I hope I didn't mislead you on that in my comment above.
If I were going to contribute to someone else's extra, I would not use MyComponent at all unless the project was built with MC -- and maybe not even then. For one thing, MyComponent has fairly rigid rules about where things go and how they are named, so you'd have likely to modify the other person's extra for that. MyComponent would also replace the person's build.transport.php, create a new project config file, and create new resolvers they've never seen before. They'd get those changes when you pushed to GitHub, and though you might be doing them a favor by making the project compatible with MyComponent, they might not see it that way.
If you're thinking about contributing to MyComponent itself, I have to warn you that it's a complete nightmare to work on. It's very straightforward to use it on another project that's built in another directory, but it's unsafe to run it directly on itself during development (hence the mycomponent2 directory), so I have a development copy, a build copy, an installed copy for testing it as installed, and to be sure everything works, another installed copy in another install of MODX that doesn't have the first three copies. In addition, there is a fifth copy of much of it in the MODX database and a sixth copy in the database in the other MODX install. It's almost impossible to keep all these straight and there are subtle differences between the various copies that make you nuts or make you think you're going nuts. For example, in the installable version, the current project is set to 'Example' but when developing, it has to be set to 'MyComponent' and I live in fear of releasing a version with it set to 'MyComponent.'
Back to your question: There are a number of ways to work on a component. For simple bug fixes, what I usually do is just
Install the package in Package Manager
Fix the bug
If it's a really simple fix, I just paste the change in a note in the issues section at GitHub.
If not, I fork and clone the person's GitHub repo, copy the fixed files over their files, commit, push the changed version to my fork, and issue a pull request asking them to pull the commit(s) from my fork.
For more extensive work, I would fork and clone their repo, build and install (or install from Package Manager if there's no _build directory).
Then, I would make the elements static (pointing to the files in my cloned repo), do the work, commit, push the changes to my fork and issue a pull request as before. If they have any development System Settings to set paths to development directories, I create them (look at any include or require statements).
Yes, repos should definitely include the _build directory. Some people have their database credentials in that directory, but those should go in a build.config.php file. The buld.config.php file should be in .gitignore, but not the whole _build directory.
