Hackster is a community dedicated to learning hardware. Hardware developers from beginner to pro are able to learn new things every day, thanks to the high-quality projects that our community members share publicly. Since the early days, we have been curating projects and helping authors improve their projects in order to ensure that what becomes visible to the broader community is of high quality. This notion is very important to us, which is why we're releasing the following guidelines for authors.
What kind of content is accepted?
Hackster is a place to share your experience with hardware, including electronics and the Internet of Things. As we try to maintain a relevant knowledge base, projects that are outside of these bounds are not accepted.
- Yes to hardware, electronics, and IoT projects.
- Yes to open source.
- Yes to original content (you own the IP).
- No projects that are simply a sales pitch for a commercial product. Consider creating a platform hub, and/or post an article showing how to use the component in a project.
- Yes to apps and software-only projects, as long as they're directly related to hardware or IoT (eg: the source code for J.A.R.V.I.S., if anybody has it, please share).
- No ads.
- No plagiarism.
- No strong, hateful or pornographic language.
What happens when projects don't fit our guidelines?
- If the project can be improved, it will simply be set aside until additional work is put into it.
- Otherwise, it is marked as rejected. It will still be accessible via direct link, as well as the author's profile.
How to ask for community input?
- When asking for help, be clear on what the project consists of and in what areas you may need their contributions.
- Remember to stay open-minded with contributions to your project as the community may want to help in unexpected areas.
- Make sure to tag your project properly so the crowd you're looking for can find it easily.
- Also select components accurately and keep in mind that the easier to source they are, the better (you don't know where in the world someone wants to help!).
General guidelines:
- Language: There are no grammatical or spelling mistakes. The text is readable by an English reader.
- Punctuation: The first words of sentences are capitalized. Sentences end with a period (full stop). Periods and commas have a space after but not before.
- Formatting: Overall, the project should look nice and be readable. Title, bold, italic, and other formatting tools should be used only when they make sense.
Name:
- Required.
- Should be a complete sentence.
- No URL in this field.
- Preferably descriptive of what the project does, instead of what it's made with.
- OK to just use a code name, like "Jarvis".
- Make it interesting enough to capture the attention of readers!
Pitch:
- Required.
- One short sentence that says it all.
- Preferably doesn't duplicate the name.
- No URL in this field.
Cover image:
- Required.
- High resolution, crisp image, good lighting.
- No text.
- Recommended to be a picture of the project's end result.
- Preferrably attractive enough that it'll capture the attention of readers; move beyond the tangle of wires!
Difficulty:
- Should be accurate.
Categories:
- Required.
- Maximum of 3.
- Since components, tools, and online services are already linked in a separate section, tags shouldn't include components. For instance, you should avoid "Arduino", "Raspberry Pi", or "Windows 10". Instead, try to categorize the project with what it achieves. For instance, a weather station could be "Weather", "Monitoring", "Data collection".
Team/contributors:
- Team members should be added as full team members, not in the "work attribution" section.
- "I'm posting this project on behalf of someone else" should only be used if someone else could claim the project as theirs. If the project was made by a team that the author is on, they should just use "team name", not "I'm posting this project on behalf of someone else".
Things:
- Required. This is how the system links to platform and part pages, so it's very important.
- Platform should be selected if any.
- The name should be the same as on the store page; additional info should be put in comments.
- Link to store preferable.
- All components listed should actually be used in the project.
- Software and tools should be in their respective sections.
Story:
- Required.
- URLs should be made clickable.
- Video links should be made into embedded videos.
- Titles should be used as section headers, not to make arbitrary text bigger.
- Code should not be left as plain text, and should instead be made into a proper code snippet.
- Images should be of the highest quality possible (think resolution, lighting, focus...)
- Imported projects should be checked for extraneous text, like text from the navigation bar, social sharing plugins, or "you might like" kind of footers.
- It's OK to have the components list in the story, but it should be added to the components section as well for better cross-referencing.
Schematics:
- Should only be used for schematics.
- No placeholders to get the checklist to 100%.
CAD:
- Should only be used for CAD files.
Code:
- The proper language should be selected for code files.
- No placeholders to get the checklist to 100%.
Questions? Contact us: help@hackster.io