Many of us at Sun are doing work that could change the world. The intent of Wikis.sun.com is to provide a mechanism where Sun Employees and invited guests can collaboratively create wiki content that supports their common efforts. As of now, you are encouraged to leverage Sun's wiki site to meet this need, without asking permission first (but please do read and follow the advice in this note).
Moderating It's important to have a designated wiki moderator that
maintains the organization of the wiki and nurtures it. The moderator
should be a Sun Employee and effectively respond to ongoing decisions
and questions that impact their wiki space. A moderator must also
remember that the wiki is owned by the community first and foremost and
must resist controlling it. A moderator should always try to "guide and nurture"
instead of "command and control."
On the inTERnet Content you post is accessible by anyone with a web connection and a browser. The site does have a private wikis feature, but keep in mind that content is NOT as secure as that which resides on a protected inTRAnet. Therefore, use additional caution when publishing to wikis.sun.com. Content requiring a non-disclosure agreement, or information considered Sun private should not be published on the wiki. If you aren't sure, don't publish it.
Don't Tell Secrets Common sense at work here; it's perfectly OK to talk about your work and have a dialog with the community, but it's not OK to publish the recipe for one of our secret sauces. There's an official policy on protecting Sun's proprietary and confidential information, but there are still going to be judgment calls.
Financial Rules There are all sorts of laws about what we can and can't say, business-wise. Talking about revenue, future product ship dates, roadmaps, or our share price is apt to get you, or the company, or both, into legal trouble. If the judgment call is tough-on secrets or one of the other issues discussed here-it's never a bad idea to get management sign-off before you publish.
Think About Consequences The worst thing that can happen is that a Sun sales pro is in a meeting with a hot prospect, and someone on the customer's side pulls out a print-out of the wiki and says "This person at Sun says that product sucks."
In general, "XXX sucks" is not only risky but unsubtle. Saying "Netbeans needs to have an easier learning curve for the first-time user" is fine; saying "Visual Development Environments for Java sucks" is just amateurish.
Once again, it's all about judgment: using your wiki space to trash or embarrass the company, our customers, or your co-workers, is not only dangerous but stupid.
Disclaimers Many community content authors put a disclaimer on their front page saying who they work for, but that they're not speaking officially. This is good practice, but don't count on it to avoid trouble; it may not have much legal effect.
Understand the boundaries A wiki should not be perceived as replacing the existing, primary information sources (product documents, knowledge articles, etc.). Pointers can be provided to existing support articles or existing product documentation. Use your wiki's policy page to make your wiki's purpose clear.
References:
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
