[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