comments inline. please feel free to point out anything which is out  
of context. As a head's up, there's a lot here to digest, which leaves  
a lot of room for mistakes *yikes*.

On May 15, 2008, at 8:13 PM, Michelle Olson wrote:

> adding to a best practices document, the basic notion that core  
> contributors must keep the web pages fresh, makes good sense to me.  
> I'm not sure OGB needs to be involved, but I'm open to your ideas  
> there. Making editing of the website crystal clear is very important  
> to me, so if you have comments on this guiding document, or how to  
> make it more visible, let me know: 
> http://opensolaris.org/os/communities/lead_reference/

My recommendation here would be that a set of information on each  
"portal" is mandatory on the "learn more" and "find help" pages. The  
required information could differ based on the type of project (CG,  
project, User Group, SIG) but it would at the very least contain:

- Announcements: community updates relevant to objectives (ie, roadmap)
- About: all the important information relevant to the project's  
purpose, objectives, vision, requirements, etc...
- Posts: contributor-submitted (blog post, journal, CMS, editorial, or  
whatever you want to call it :)

The concept is that the "learn more" page would be consistent  
throughout the community and provides a means to collaboration between  
the visitors of the site and the project and it's contributors.  
Moreover, community leaders would have the means to keep their site  
updated without having to worry about how it's laid out or what  
information is mandatory (the application would require it).

I believe the posts should be optional, but the announcements and  
About would be mandatory. Personally, I would post to any community I  
contributed too, but others might not do the same. I wouldn't want to  
force contributors to "blog", but it would be there if they chose to  
use it. If the post functionality was very easy to use and 'in your  
face', we could almost hope for a twitter effect. Who knows... maybe  
some communities *cough* advocacy *cough* could have twitter  
integration.

I bring up twitter merely to convey an idea of collaboration and  
discuss the concept, not necessarily committing to coding such  
functionality ;)

>> Apologies for picking on storage, but it's the first one I picked  
>> and it's evident the storage community is trying to be verbose with  
>> monthly updates (a good thing).
> OK, I'd like to hear from you some easier ways to contribute that  
> you would expect to see. Let's also use the documentation community  
> as the example, since I developed those pages and I'd rather bring  
> commentary on my own work than on someone else:
> http://opensolaris.org/os/community/documentation/

Documentation is interesting because it's acting as both a community  
and a functional point of reference. In contrast, the storage  
community site has no documentation on it.

Are announcements as important as keeping the site up to date?
http://opensolaris.org/os/community/documentation/announcements/

I saw a post on the mailing list recently with a major docs  
announcement, yet the information isn't on the site. While this type  
of information isn't necessarily important to someone consuming the  
docs it would be important to anyone interested to contributing to the  
docs themselves and/or the general docs community at large.

Now aside from collaboration, content, and consistency, there is also  
a conflict present which is very visible in the documentation  
community. The paradox present is that the site is serving both as a  
reference and a point of [one-way] collaboration. It is a resource for  
contributors to get involved and a point of reference containing the  
content which is published by the contributors.

As an abstract example, what if the front of the storage community had  
the same form factor of the documentation community? Upon accessing  
the storage site you would perceive it more as a point of reference  
than a means of facility for contributions.

This is why in the link layout towards the end of the original email I  
recommend breaking out the "participate" navigation into the actual  
participation links. An end user who is visiting the community for  
support or reference will *immediately* recognize and find useful the  
learn more and find help links whereas a contributor will immediately  
start clicking on the bugs / wiki / contribute links. As proposed  
previously, the learn more page would be the "landing page" and  
provide very useful and relevant information to contributor and end- 
user alike.

The only major concern I have here is what role opensolaris.com plays  
for end users. Should the documentation os.org portal contain the end- 
user reference content, or should that content be explicitly published  
to the os.com site? I don't think we have to answer this question now  
- I think we can easily simplify the design so it is not a problem,  
however, we can also keep this question in mind and maybe one day ask  
ourselves "Should the os.com site have an end-user extension of  
published content which is pulled from the os.org site?" The idea  
being that the os.com site would *only* display content relevant to  
"learn more" and "find help", but it would be maintained and fed from  
the os.org site. I hope this 'extended suggestion' along with it's  
explanation helps to sort of set the stage for what we can do to  
simplify os.org now to both promote collaboration and improve overall  
ease-of-use and functionality. /mouthful

>> I would be very careful though, to make major changes at this time  
>> which are not trivial with regard to "community". Not only is the  
>> current idea of collaboration lacking in the current site,
> Can you clarify what you mean here? I'd like some more specifics on  
> the 'idea of collaboration lacking' problem from your perspective,  
> if you have time.

The idea of encouraging participation from the visitor to the site and  
vice versa (the contributors having an open dialogue with the  
community via the site). Maybe not something as important right now  
but something I believe will have more relevance as the community  
becomes larger (publicly). The idea I propose is the "learn more" page  
details mentioned above. The other forms of collaboration (ad hoc)  
would be the wiki.

A quick note: I think the attachment of blog posts to the project  
front pages may have been a first step towards social collaboration  
but they're below the fold and a lot of times not relevant to the site.

Another side note, the blog feed idea could be improved upon by having  
the bloggers categorize relevant posts which the os.o site is  
configured to look for - most blogs allow you to hit the rss feed with  
"/category/opensolaris" to grab only posts tagged with the opensolaris  
category. Example: http://nessence.net/category/opensolaris/

>> Right, good point. I'm well aware of the conversation happening on  
>> OGB (as the secretary, I have no choice!), so the two efforts will  
>> be coordinated. But, feel free to keep me honest here, I agree that  
>> there is such a risk.

Just pointing it out for the discussion/lurkers ;) on the list.

>> With regard to a brainstorm idea, -1. There are already WAY to many  
>> places to submit ideas or concepts and adding another one sounds  
>> like a great idea but I think it would be a desolate place. Maybe  
>> it would be a good idea after the next version of Solaris is  
>> released; I don't believe any of the ideas posted would get  
>> significant attention until OpenSolaris has reached that milestone.
> Now I'm a bit confused, but are you talking about os.org here?  
> Because this seems to conflict with your statement about about the  
> site 'lacking the idea of collaboration'. Maybe some clarification  
> on the above will help me understand more.

I see collaboration as people discussing ideas with each other and the  
smaller groups work as a whole to a greater goal. High aspirations, I  
know. However, a site which let's individuals post their ideas and  
which others vote them up or down with no recourse on their vote and  
nobody responsible for following up and being accountable to those  
ideas just creates a site with a list of ideas. I'm not saying that  
isn't cool, but I think right now there's nobody around to give  
attention to those ideas.

If there IS somebody at Sun who is interested in those ideas and can  
do something productive with them it's not a bad idea after all. I  
think that would necessitate a discussion about how that communication  
would be advocated and not necessarily whether it's a good idea.  
(Because then it would be advocacy, which is not the same thing as  
collaboration)

To answer your question, I don't consider it collaboration because  
it's a one-way conversation - just reading brainstorm.ubuntu.com and  
the comments posted there makes that somewhat evident.

I don't rule out this idea on opensolaris.com when the OS is more  
mature and has a greater userbase. Ubuntu, as with sites like digg,  
already have a large enough user base that brainstorm idea works for  
them. If we put it up now then there'd maybe be 5 votes a day  
(pessimistic guess, I know). I'm also pretending like there aren't  
hundreds of Sun fellows who would use the site, but I'm expecting they  
don't have problems finding a channel to submit their ideas.

If I'm totally off-base here (I wasn't in the face-to-face meeting),  
then feel free to disregard and/or discuss/veto :)

>> As far as an approach to improving collaboration I would ask that  
>> editorials and solid wiki integration be a priority - as they kind  
>> of go hand-in-hand. Although I'm not sure exactly what "editorial  
>> functions" represent - I assume this means a CC or contributor's  
>> ability to keep their site updated with objectives/progress/ 
>> direction without having to know HTML or worry about how it's laid  
>> out.
> The site content currently is authored in TML (a wiki-like markup)  
> or HTML, which is very awesome because it allows you to do either,  
> depending on your preference. Layout is definitely also something  
> contributors need to deal with. So, we're 0 for 2 on this one if I'm  
> understanding you (I'm not sure that I am). But, this is all easy  
> for me to say, since I have leader privileges for a number of  
> communities and projects. I'm starting to think you're saying that  
> getting Leader privileges is the main blocker? I'm certain that I  
> haven't made this process clear for at least one of the communities  
> I manage, so it seems like good fodder for the best practices  
> document also.

That does sound awesome (I'm not a leader, so I don't know what's  
behind the curtain)! So what I'm submitting is that the format become  
more consistent and the freeform editing be in addition to the  
requirements of required information (in a consistent, standard format).

>> Learn more - find help - get source - participate:
>> This sounds like a great direction, consistency is good, however I  
>> would like to see 'get source' and 'participate' removed or  
>> possibly separated out with their own navigational elements of "Bug  
>> Tracking", "Wiki Docs", "Source", and "Contribute". I'm not sure  
>> where mailing lists fit here but the goal would be to have these  
>> pages link to or integrate with content for these [external] systems.
> Yes, this is exactly my thought also, that each community or project  
> would include in the landing page for 'get source' or 'participate'  
> links to the associated bug tracking tool, wiki pages, source  
> repositories, etc.

So the trick/challenge here are projects like documentation, which as  
noted above, are currently dual-purpose. Should all projects or  
communities be dual-purpose like docs?

>> - Bug tracking could pull the relevant defects that are  
>> outstanding, have a link to submitting a bug, and a list of  
>> recently completed bugs.
>> - Wiki docs would be a freeform wiki - this is where the community  
>> is allowed to be ad hoc!
>> - Source would be all the typical details associated with source  
>> code along with links to the "community standard" contribution  
>> guidelines and instructions on how to contribute to the type of  
>> repository setup the community/project uses
>> - Contribute would be filled out by the CCs with all of the details  
>> pertinent to contributing to the project and/or the projects impact  
>> on other projects/sites
>> - Learn more could be the "home page" with objectives/direction/ 
>> progress and social editorial functions. Maybe twitter could be  
>> integrated?
> I like these ideas!

Great. Once we've discussed everything we can try to compile a list  
similar to your wiki list so we can start to milestone these new  
features against existing tasks and bug fixes...

>> Just some ideas, but the underlying concept is to make the site for  
>> each project/community about collaboration and communication, not  
>> about advocacy, interaction, or perception. Not that I think these  
>> were the goals, but I believe those values are better served on  
>> opensolaris.com than the developer-centered opensolaris.org.
> Agreed, for the first three years, we on os.org had to do both, so  
> now we have some significant cleanup to focus a bit more. For each  
> community and project this will be a bit different, but I'm  
> confident we can develop best practices that are generic enough for  
> everyone to relate to and provide strong examples that are easy to  
> adapt. yes, I'm a dreamer :)

Agreed. I also believe we can make all of these useful changes without  
worrying about what happens with any structural changes which result  
from OGB decisions.

Again, I hope I'm being helpful here and not selfish (I'm rather picky  
and opinionated).



Alex Leverington
_______________________________________________
website-discuss mailing list
[email protected]

Reply via email to