When to create a document? Document about code from Discussion

[Former Member]

Hi All,

Let me give you an example about the given topic.

Say I'm working on getting a discussion question answered for someone else.  I produce some code to help them.  The question is closed.  Then I see that the question seems to recur.  Referring back to the original question is not so helpful, because the original answer was not generalized enough and was not documented enough.  Surely everyone understands that such will never happen in a discussion.  So should I be allowed to create a document that generalized and documents my answer, so that when others ask similar questions, they can be referred to the document?

The reason I ask is that I've had several documents deleted because they were deemed to not be unique enough.  A case could be made that since a similar question was asked and answered in a similar way, that the document is superfluous.

I just want to do this right!

Neal

[ThomasZloch · Accepted solution]

I think that's a good approach, in case your document has a certain "threshold of originality" (I looked this up), which actually should apply to all content that is posted.

For example, I keep referring to because the symptoms are being reported every so often in discussions. A nice side effect (when linking properly) is that you will soon have a bunch of related discussions in the "Incoming Links" section of the document.

Please do not post just the link though, a one or two liner why it is relevant to the reported problem is always appreciated.

Thomas

[JL23 · Accepted solution]

I recently saw a blog (and clicked abuse) where the user had just copied and pasted question and answer from a the discussion  - this is certainly not wanted.

[Former Member · Accepted solution]

I guess I'd take it one step further, that there needs to be a significant difference between the original and the document.  Changing a few words is insufficient.  As would be reproducing 50 lines of code to change 1 line.

But what is "significant" is pretty much open to debate isn't it?

Neal

[JL23 · Accepted solution]

Imagine you created a wonderful document, have spend hours or even days to complete it.

Someone reads it and likes it so much that he gets the feeling he has written it himself and posts it everywhere as his own document.

Would you like that?

How much do you think he has to change until it becomes really his document?

[Former Member · Accepted solution]

Oh, I fully agree!

There is also no stopping the determined thief. 

So I believe you have to pick a line.  Say this is the line!  We will enforce to this point. 

Try to put the line somewhere that you are consistently willing to enforce and that will also make it difficult for the thief.

Neal

[Steffi_Warnecke]

What about the wiki? Couldn't there be an area like " frequently asked questions" where you would put (little) stuff like this? And then you could point to the wiki article.

*just brainstorming*

[Former Member]

How are Wiki's created? Where?

[Steffi_Warnecke]

Hello Neal,

SCN has a wiki. ^^ I never created an article there, but read some.

This one here: http://wiki.sdn.sap.com/wiki/display/WHP/Home

I don't know, how to create something there (although that would probably be the easiest part^^), BUT I don't know if entries like "FAQs" for certain spaces are even allowed.

Here is the FAQs article for the wiki itself. That should answer pretty much every question. *starts to read it, too*

EDIT: Okay, the first part says it all.

What is the Content and Structure of this Wiki?
Main criteria for choosing to put content in the WIKI is its volatility and dynamics, extendability and/or collaborative character. Ask yourself the question, if you want others to be able to change, extend, regroup, add, etc. your contribution. WIKI Content should also not express personal opinion (like in blogs).
WIKI content can be of many flavors, and could fall under the following categories:
Frequently Asked Questions
Guidelines & Best Practices
Modeling & Coding
Modeling & Coding Templates
Bibliography
References/Links
Learning
Glossary

If I read it right, the wiki would be the perfect place for what you have in mind. But maybe someone from the team can shed some more light.

Regards,

Steffi.

[Former Member]

My "rule of thumb" for wiki creation is; if it will essentially read as a book with chapters and subchapters (some call hierarchical organization) . E.g.;

Car engines

     Internal combustion

          Gas

          Diesel

               Clean Diesel

               Normal Diesel

          Hydrogen

     Electric

          Pure

          Hybrid

     External combustion

          Sterling (?)

           Coal

          Something else

Not sure if that would fit your requirements. I'd argue not, unless you plan to be adding content that naturally organizes as above. For more of my musings see the blog Sharing Knowledge Is Not That Hard - Wikis.

- Ludek

[Former Member]

So maybe I'm thinking this backwards.

If on seeing the question, I created the document and then referred the question to the document?

Is that putting the cart before the horse?  Should the need be proven by the repetition and therefore it then become a document?  Or should I start out with a document and then point the question to it.

Obviously, only complex answers deserve a document.

Your thoughts?

Neal

[Former Member]

Hello Neal

My view would be that something like this would make an excellent Document. I'm working on a series of blogs on when to write what (doc, wiki, blog, etc.). My view on Documents is in this blog:

http://scn.sap.com/community/about/blog/2013/07/18/sharing-knowledge-is-not-that-hard--jive-document...

Now, the above is my view only, thus a blog (my soapbox ), but in the blog I also reference other sources that describe the when of a Jive Document. And these "jive" pretty well with my views.

- Ludek

SCN Moderator

Senior Support Engineer AGS Product Support, Global Support Center Canada