Submitting a Project to Branch? GitHub Best Practices
Submitting a Project to Branch? GitHub Best Practices
Thinking of submitting a project to a GitHub Branch? Here are some Best Practices to consider when creating an open source project on GitHub.
Join the DZone community and get the full member experience.
Join For FreeJumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
A couple nights ago, I had the opportunity to attend my local JavaScript Meetup here in Ottawa. Our second speaker was Simon MacDonald giving a talk entitled Maintaining Open Source while Maintaining Your Sanity. I enjoyed the talk so much I thought DZone users may benefit from some of the points Simon laid out.
Now, I'm not in any way saying these practices are a requirement in order to submit your project for approval. These are simply suggestions that will make it easier for other developers to navigate your project, and possibly even help make it better.
Include a README
Including a README file in your project is pretty essential. It should give developers looking at your project the essential information they need, including:
- An overview of the project. This will give the developer a good idea what exactly your project is trying to accomplish.
- A getting started section. This should be a simple set of instructions that will get the developer up-and-running with the project as quickly as possible.
- An invitation to contribute. One of the great benefits of open source is the ability to collaborate, so if you would like other developers to help you improve your project this section will encourage that.
Include a LICENSE
While this is never mandatory, it is incredibly important in the open source community. To quote a GitHub article regarding open source licensing:
"Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work."
The absence of a license is kind of the opposite effect we try to accomplish with open source, so including an open source LICENSE is key. You can use pretty much any open source license you wish and GitHub gives you a bunch of different options when creating a repository, so have a look.
There's plenty of more information in Simon's slides about handling collaboration when you have an open source project, but I just wanted to point out the main setup points here. Feel free to have a look at the entire presentation if you want to know more about keeping your hair when maintaining open source.
Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.
Like This Article? Read More From DZone
Published at DZone with permission of Rey Riel , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}