...
- if you want to publish a solution that you are proud to have invented then don't forget to mention the underlying problem that you solved.
- A good approch approach is to start an article by clearly stating a problem:
- Most problems stem from user expectations that have not been met.
- In other words, clearly state the gap between user expectations and the effective behaviour behavior of the product.
- A perfect approach is to elabore elaborate the user requirements in your article. This sounds simple, but in fact it is not:
- Most users would tell us what they want, not what they need.
- There's a subtle difference between these terms:
- Users who request a functionality tend to suggest some solution how a function or operation should work. This is what they want.
- Users who describe their usage scenario state what they would like to achieve. This is what we call a user story and is a functional requirement.
- Development of a solution always starts with valid requirements, not with a wishlistwish list. There is no chance in developing a sustainable solution when skipping the requirements elaboration.
- If the solution that you describe in your article would not satisfy all thinkable requirements then this is not a disaster. At least if you clearly state to what extent the solution meets the requirements of the starting situation.
...
- It is always a good idea to have someone review your article.
- Receiving a second opinion might help to discover aspects of topic that were out of your radar.
- The famous saying that there is more than one way how to do it, is particularly true for our products.
- Use the share operation that is available on every page in the knowledge base to invite other users for review.
- Add two possible labels to your page:
- review-editing: to have someone review language use in the page.
- review: to have someone review the technical content of the page
Accept feedback
- This site provides some mechanism for ratings and surveys.
- Feedback is not necessarily about receiving applause. Never take a negative feedback personal and never discuss with posters.
- Feedback presents someone's perception of an article and therefore is neither right nor wrong.
- Instead, try to understand what problem has been perceived and if you could accept to modify your article to comply with the poster's perception.
...
- So you think you're done having received some feedback on your article? Definitely not.
- Articles tend to become inaccurate and even obsolete by ageingaging. This might be due to newer versions of the product or updates to the environment.
- Therefore add an expiration date to your article, e.g. for six months later. When that time has come then you will be notified by mail that your article has to be reviewed or otherwise will be marked as invalid.
- At the time of writing articles are automatically proposed for review one year after the last update.
- Specify an individual expiration date by adding to your page a label with the name expire-single-yy/mm/dd, e.g.
expire-single-15/02/28to get notified by end of February 2015.