OK, I understand. As a point of clarification. I have a complete set vis a vis openoffice.svn sites of all "accepted" and "incubator" projects which I am now cleaning up and importing into the ooo-site svn tree.
So, no matter what we decided ultimately about the ooo-site tree, we we will ahve copies. Given the large size of some of these areas, I was just concerned about the import of some of them *at all* into the ooo-site svn tree. however, I know they really do need to be someplace where all the project committers (and contributors) can access them in order to be of any use right now. So, I will get back to the import process on Friday, and hopefully, can get the legacy "accepted" projects in the ooo-site tree for further evaluation by SUnday. On Wed, Nov 23, 2011 at 11:55 AM, Dennis E. Hamilton < dennis.hamil...@acm.org> wrote: > My recommendation is that everything in terms of web pages should be > preserved that is not already captured in the bugzilla, MediaWiki, and > Community Forums. > > Cleanup can happen on our ooo-site SVN in anticipation of the cut-over and > after the cut-over. The remodeling to divide up the site content and also > provide adequate portal operation from openoffice.org to the Apache > OpenOffice development/project site does not have to be completed, or even > started very much, prior to cut-over. It is something to nibble through > when there is no time-limit over our heads and the keys to the live content > are in our custody. > > - Dennis > > -----Original Message----- > From: Kay Schenk [mailto:kay.sch...@gmail.com] > Sent: Wednesday, November 23, 2011 08:56 > To: ooo-dev@incubator.apache.org > Subject: Re: Rationalizing two OpenOffice websites > > +1...all good, and something we had discussed early on. > > However, as I work on porting legacy info over, I am wondering what to do > about the more "developer" centered areas of the site: api, sc, sw, > framework, external (? -- I need to look at this one), tools,porting, and > many others that are not really "user centered". I will load these into the > ooo-site tree, but at some point, someone on the "developer" side should > really cull this out and move them to the "developer" side so we don't > continually deal with these areas on the "user portal". > > On Mon, Nov 21, 2011 at 3:46 PM, Rob Weir <robw...@apache.org> wrote: > > > We have with this project something that most other Apache projects > > don't have and which the legacy OOo project never had. We have two > > independent websites. > > > > We have the legacy www.openoffice.org website, which served as an > > end-user portal for OpenOffice as well as a website for project > > participants. > > > > And we have the http://incubator.apache.org/openofficeorg/, which on > > graduation probably becomes something shorter, like > > http://openoffice.apache.org. For most Apache projects their website > > also serves both purposes: a site for users as well as project > > participants. > > > > So, we have both of these websites, and a lot of redundancy caused by > > it. This obviously has a downside. It makes it hard to update, since > > a lot of information is in both places. And it confuses users since > > the websites are out of sync on some important topics. It also > > prevents us from really optimizing the experience for each audience. > > I suspect that long-term this dual-website with overlapping content is > > not a maintainable model. > > > > What can we do? > > > > I hope I am not committing heresy if I say that most users of > > OpenOffice care as little about Apache as drinker of a Pepsi cares > > about the Board of Directors of PepsiCo Corporation. The average user > > (and we're talking about millions of them) cares about downloading, > > installing, using, learning about and generally being productive with > > OpenOffice. It is a tool they use to do their work. Their work is > > what matters to them, not our work. > > > > But of course we also have a growing number of users, contributors and > > committers who want to get more involved with the project. OpenOffice > > is interesting to them. They identify with it. They want to learn > > more than just the basics. They are intrigued by open source. They > > want to help. They want to get more involved. > > > > The trick I think, is to have websites that speak to each of these > > audiences, as well as an easy/obvious way to navigate between them, > > while at the same time avoiding unnecessary cross talk and redundancy. > > > > For example, could we have something like this: > > > > 1) www.openoffice.org is the website for the OpenOffice product. It > > is the end user site, focused on their interactions with the product. > > So download, help, extensions, support. It is not how they interact > > with the project. It serves the narrow focus on the product. > > > > > > 2) incubator.apache.org/openofficeorg (eventually > > openoffice.apache.org) on the other hand is where the project members > > work and where the public (includiing users) interacts with the > > project. Not the product, but the project. > > > > This dual website is quite commonly used for managing large and > > important brands. For example, the consumer, when interfacting with > > the brand Pepsi and Pepsi products goes to: > > > > http://www.pepsi.com > > > > But the person who wants to learn more about the company goes to another > > URL: > > > > http://www.pepsico.com/ > > > > Navigating between then is possible via a link on the page footer. > > But generally each site is optimized for its target audience. > > > > > > -- > > ---------------------------------------------------------------------------------------- > MzK > > "The greatness of a nation and its moral progress can be judged > by the way its animals are treated." > -- Mohandas Gandhi > > -- ---------------------------------------------------------------------------------------- MzK "The greatness of a nation and its moral progress can be judged by the way its animals are treated." -- Mohandas Gandhi
