Make sure the message is addressed to wide user community. If it is a targeted message for a specific community, consider using specific communications channels like:

• Targeted e-mail message to specific community (e-group) or 

• Request a targeted alert message (eg. Building 513 users) via the Portal

Make sure the message is posted in the right SSB category under:

• Incidents

• Planned Interventions

• Service Changes (foreseen, recent or Important)

  Sometimes it is not clear if an article should be posted as a Service Change or Planned Intervention. Here are some criteria that might help you decide:

  • When posting a Service Change to the SSB, you can choose the time it remains visible on the SSB Home page. A planned intervention appears on the SSB Home page only the day of the intervention.

  • A Service Change alters the functionality of a Service from the user point of view. In that sense, patching is not a Service Change but rather an Intervention.

  • The end of a Service or the replacement by another is a Service change.

  • Anything that introduces changes in the way the user interacts with a service should be posted under Service Change.

  • Fixes, upgrades to more recent versions, patching etc. should be posted as Planned Interventions.

  • You can post a Service Change and a Planned intervention for the same event, if putting in place the Change has an important impact to the current service.

Your message should be:

• Short. Additional related information must be given in the posting via a link to another page.

• Precise. It is no use to say ‘many services will be affected’. You must list at least few major services affected. Following these, a general statement as above, is acceptable.

• Accurate. Make sure that the dates in the message are ‘real’ dates (most are now auto filled but there might be other dates in the text). Do not use relative references but instead use absolute ones (e.g. the exact date, i.e. Friday 25th of May instead of ‘tomorrow’). Do not use approximate terms like ‘about 2hrs’ but precise ones even if it means that you have to add more time in order to be on the safe side. In fact, you should include a safety margin in your timing.

• Prioritized. Have the most important information from the user’s point of view at the beginning and not buried under other information.

• Clear. The message should be jargon free. Technical terms should be substituted by problem descriptions from a user’s point of view whenever possible. This should be done in a systematic way.
  For example ‘problems were due to "memcache" and "caching"’ should be translated to, ‘the incident is related to a configuration issue on the server’.
  Users are not looking at the SSB to find detailed technical explanations but for a quick understanding on how they are or will be impacted.

• Correct. The language should be appropriate and correct both grammatically and syntactically. The SSB is visible to the outside world and thus utmost care should be taken of this. It should be cordial but impersonal. Do your best and rely on the moderators to make any correction.

• Timely. When posting a Planned Intervention or Service Change, make sure you give enough advanced warning for users to react and adapt their work. Depending on what you post, this can range from several days (4-5) to few weeks. Urgent, necessary but unforeseen interventions should be clearly marked as such.

Do not hesitate to communicate with the moderators (it-dep-sims@cern.ch) if you have any doubts or questions.

For Incidents, remember to regularly post updates in the SSB. A reasonable interval is at least every hour from the moment you posted the incident if it has not been resolved, more if you have any important news like a workaround or a temporary solution. Always provide a ‘resolution comment’ or a post-mortem for incidents with widespread impact.

Please note that as an IT SSB Contributor, you are responsible for the content you provide, as well as ensuring the timely update, resolution and closure of articles on the IT SSB.