[osol-mktg] Proposing a website design revision process

Stephen Hahn sch at eng.sun.com
Fri Dec 16 15:06:54 PST 2005


* Laura Ramsey <laura.ramsey at sun.com> [2005-12-15 05:38]:
> This is great--and thanks for the invitation. We have a few "cosmetic" 
> ideas that we'd like to forward. They are by NO MEANS p1 sort of 
> changes, and so do NOT have to happen before January--But they are 
> things that would give the marketing and user group activities more 
> visibility up front, and help drive clicks.
> 
> What is the best approach for sending these along?

  Derek and I were just talking about this earlier today.  While we both
  have concerns about general design goals, we would like to get to a
  method for identifying, tracking, and resolving smaller issues.
  Here's my proposal

  1.  Realize some piece of information is missing, awkwardly
      represented, or difficult to discover on opensolaris.org.  Search
      the website-discuss forum to see if it's been mentioned before.

  2.  If it's really small, like a typo or error in grammar, just
      summarize the change in a mail/posting to website-discuss.
      Someone will either make the correction or ask for clarification.
      If this discussion doesn't resolve, the change wasn't really small
      and you're on to the next step.

  3.  If not a small change, use

      http://www.opensolaris.org/bug/report.jspa

      to file a bug in the opensolaris/website category.  The Synopsis
      field should start with "*design*".

      For example,

      *design* front page link to opensolaris store needed

      is a recently relevant example synopsis.

  4.  Someone on the website team will look at the submitted bugs and
      propose a possible change to the forum.  Alternate proposals and
      criticism will be entertained, with a resolution for up to medium
      sized change--new elements, new attachments, etc.--within two
      weeks.  A final proposal will be offered for general consent, and
      then to a vote.

  5.  A short email for the correction or change will be sent to confirm
      that the change was made.  The bug, if any, will be closed.

  This process isn't meant to handle large site changes; we'll need to
  think about how to handle those--at present, the feature support for
  source code management and governance is driving larger changes.  Once
  we've built the initial versions of each of those, we can use this
  process to refine them.

  Comments?  (So, Laura should get her list together and decide what's a
  correction and what's a change (and what's too big, but extremely
  important).)

  - Stephen

_______________________________________________
opensolaris-mktg mailing list
opensolaris-mktg at opensolaris.org



More information about the opensolaris-mktg mailing list