I couldn't help but noticing there was very little on the roadmap... So why is it that none of the communities and/or projects have direction?
I know that's *not* true - they do have direction. However, it would be good to see within the redesign a focus on the objectives, direction, and progress of communities and projects. It should be easy and straightforward for the community CCs to update this information. Lately there has been talk on OGB about core contributors and communities dissolving based on lack of contributions. Unfortunately no such provision exists with regard to a core contributors responsibility to maintain their website - let alone that doing so right now isn't a crystal clear process. While it's good to be loose and leave it up to the community, the mere process of the OGB to authorize a community dictates that having one is a responsibility and not just an ad hoc establishment. A good example of current confusion is the recent storage community announcement: If you look at the storage community here, http://opensolaris.org/os/community/storage/ there is no mention of the information here: http://www.genunix.org/wiki/index.php/Storage_What%27s_Happening_April_2008 ...which was posted to the mailing list. Now this is a link that *does* show up on the os.o page: http://www.opensolaris.org/jive/thread.jspa?messageID=235076&tstart=0#235076 (it's old news!) Basically, if I want to participate in the storage community, I need to: - keep up with mailing lists (plural) - read the os.o front page - keep up with the wiki page, which isn't actually linked to from the os.o page - understand all of the *other* complicated things that have to do with contributing to os.o And of course, I have no idea what's going to show up on os.com for the storage community... 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). I do not want to detract from navigation, internationalization, or the other topics which are evident priorities, especially internationalization. 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, the OGB is currently discussing re-architecting the entire hierarchy of the community and it's members. It would be unfortunate to set new best practices, create new channels of communication (ie, brainstorm), or add any other new functionality (editorial) if it will need to be re- adapted to the new roles of communities and their members. 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. 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. 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. - 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? 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. I hope these comments are helpful and I hope my goals in submitting these comments are evident. Primarily, opensolaris.org and it's many mailing lists become less of an information overload for us all and second the folks outside the firewall are able to find it easy to navigate, participate, and collaborate within and among the opensolaris community. Within and among are very important. -- Alex Leverington On May 14, 2008, at 7:54 PM, Michelle Olson wrote: > Hi all, > > We had a 2-hour face-to-face meeting last week so I could get educated > on all of the issues that touch website content. Find what I learned > below. (I will setup a conference call for all of us to meet when > Alysson returns from vacation, so you know I haven't forgotten about > that request.) > > Attendees: > Jim Grisanzio > Derek Cicero > Bonnie Corwin (first 1/2) > Michelle Olson > Bill Rushmore > Eric Boutilier (first 1/2) > > Agenda: > 0. OpenSolaris web site application > 1. Splash pages for launch > 2. Poll data, wiki, and re-structuring communities > 3. Navigation > 4. Best Practices > 5. Submit Content > > Notes: > 0. OpenSolaris web site application > > The last version upgrade to the OpenSolaris web application (webapp) > was > delivered in Nov. 2006, to v.1.82. Since that time, we've been keeping > the lights on and integrating new components based on the priorities > for > new things like bugzilla, polling, code review, and the effort to open > source the web application code. We are about two months away from > being > ready to upgrade the webapp to v1.91. This has a new version of jive > and > some other goodies that we need in order to be fully up-to-date. > > 1. Splash pages for launch > > I put this on agenda to enable any residual feedback to come out and > to > ask if the portals were going to translate the new pages. Jim felt > that > because the splash pages are temporary and because there is a lot of > planning happening for new site infrastructure to handle localization, > we should not begin an effort to have the splash page content > translated > by the portals. We did agree to let the splash pages 'soak' for two > months, so we'll revisit those on July 5th. > > Infrastructure for the portals is a non-trivial project, so we start > with requirements, here is a beginning: > http://opensolaris.org/os/project/portals/portals-v2/ > > We tried not to spend too much time on this topic, but it was hard. It > is a huge topic with many issues. Jim and Alan are leading this up > with > our G11n partner engineers and we'll communicate more as we know it. > > 2. Poll data, wiki, and re-structuring communities > > I had this on agenda because the voting members of OSOL put addition > of > a wiki as 5th priority in 2007 poll and 4th in priority in the 2008 > poll. Re-organization of communities and projects also ranked 4th in > 07 > poll. The OGB started discussing re-organization of the communities > and > projects at yesterday's meeting. Watch ogb-discuss for more on that > coming later this week. > > The discussion of a wiki for the website content meeting was declared > out-of-scope because we didn't have the right people on the call, so > we > didn't pursue it. But, I went back through the mail on the topic from > last year and put together a requirements candidate summary page here: > http://opensolaris.org/os/project/website/wiki_requirements/ > > To be sure, the wiki/CMS need still exists, I'll report out when I get > time with the folks who are just now picking up the evaluation based > on > the requirements gathering we did last year. > > 3. Navigation > > Navigation of the web site is an issue that has two components, > taxonomy > and editorial. Taxonomy is the site map and two forms of navigation > (left-navigation bar and upper-right icons). Editorial is how we > pull-through links to components in running text or in banner adds on > the right side. Omniture data can inform us a great deal about where > people go on the site. But, it can't tell us much about how they get > there. I agreed to pour over the omniture data for the site in > preparation for preparing studies (usability/feasibility) on the > navigation elements. > > In parallel to reviewing the statistics, I'll begin an audit and > reviews > of the common pages of the site using website-discuss list. You'll > soon > see review requests from me starting with the Roadmap, Site > Guidelines, > About, FAQs and then all the pages on this list: > http://www.genunix.org/wiki/index.php/Website_Editorial_Board > > This morning, Bonnie updated the Roadmap here: > http://www.opensolaris.org/os/about/roadmap/ > > 4. Best Practices > > Related to the topic of editorial functions of the site, we talked > about > crafting some best practices for communities and projects to improve > the > usability of their areas of the site. My opinion is that using the 4 > buckets for each project or community (learn more, find help, get > source, participate), like we did with the splash page, could go a > long > way toward improving and making a more consistent user experience. > I've > done this with the docs community and I think it helps, but I'm open > to > ideas about best practices beyond this, and I think I'm on the hook to > produce something along those lines and do some outreach to projects > and > communities to implement. > > 5. Submit Content > > Just as a final masochistic self-flogging, I broached the subject of a > 'submit content' button. This is a bad idea on so many levels > because it > doesn't scale and would be impossible to manage properly and it > thwarts > a number of other processes we already have in place for contributions > of code, docs, etc. However, it was suggested that possibly user > profile > pages could be altered to allow members to upload content of their > own, > which didn't fit on a project or community. This could include > pictures, > podcasts, presentations, etc. Also, a couple of folks have mentioned > brainstorm.ubuntu.com as a good way to manage a stream of submitted > ideas, so maybe we could do something similar for our project in > future. > > Thanks, > Michelle > > > > > > _______________________________________________ > website-discuss mailing list > [email protected] _______________________________________________ website-discuss mailing list [email protected]
