From Developer Community
Any relevant content is better than no content
Actually, there may be cases where this is not true, but in general I think it is accurate. If you think that a topic could be of value, it probably can be of value. Better to add it and have nobody use it than to not add it and leave a need unmet.
Empty topics are still valuable
If you think of a topic where you wish there was information, go ahead and add the topic. Maybe someone else will fill it in later.
Linking to another's work when possible
This is a community effort, and we don't pretend to think that we know everything about everything. Before spending time writing an article on a topic, look around on the internet and see if someone else has addressed it already. If so, take the following actions:
- Summarize the article in a single paragraph (usually copying the executive summary is sufficient), and provide a link to the original.
- If there are multiple articles or resources, repeat for each one you want to reference.
- If the article(s) you chose do not completely cover the topic, start with them and fill in the gaps.
- If the article(s) you chose do not apply completely to SUSE Linux, we invite you to complete the article by indicating what the differences there are to apply the topic properly to SUSE Linux.
Write articles that you care about
If you cannot find a web resource that adequately covers your topic, go ahead and write the article yourself. Or, even if you find one that covers it, you can still feel free to write your own article.
Including Sample Code
- Use sample code. Relevant sample code will always help to clarify content by providing a concrete example.
- Anything can be sample code. Sample code can be anything from a single line to a complete application with thousands of lines of code. It can be written in anything from assembly to C to Python to shell script.
- A non-copyleft license or public domain is good for sample code. The purpose of sample code is to show someone how something is done, and to provide the code so they can use that same code in their application. Be sure to select a license that allows them to use the sample code how they want. The BSD, Apache, MIT, and zlib/libpng licenses are examples of licenses that should be suitable for sample code. Releasing code into the public domain is also acceptable (which basically means people can do whatever they want with it).
- Don't use proprietary code. If you are submitting sample code, be sure it is not proprietary code. If you are an employed coder, check with your employer to see whether your code is considered proprietary.
Not every single line of code written for a company need to be considered proprietary. For example, I've written simple counting loops to go through arrays for every software company I've worked for. I wouldn't consider that code to be proprietary, since I learned it from a book in college. However, code that implements a trade secret or a patented technology is definitely proprietary. If in doubt, consult with your employer. Don't submit code against the wishes of your employer.
- Certain open-source-licensed code should not be used, either. Don't get me wrong; I am not anti-GPL. However, copyleft open source licenses like the GPL are not good licenses for sample code. Why? Because most consumers of sample code expect to be able to use that code in the application they are writing, which may be of another license type, including proprietary. Sample code covered by a copyleft license requires that the application that includes it be of the same license if that application is ever redistributed. This defeats the purpose of sample code.
I am not saying that applications should not be covered under the GPL license, or any other copyleft license. What I am saying is that those licenses are not good candidates for sample code, due to the common use of sample code. You may wish to read Choosing an Open Source License for further information.
Be ethical and legal
In doing all of the above, be sure that you:
- Never submit copyrighted work without permission.
- Never link to web resources that expressly forbid linking.
- Never portray another's work as your own, even if it is not copyrighted.
