I think these kinds of developer/power-user/extension user/developer changes need to be made carefully, since OO.o 3.x releases are still out there and are the only official releases under the lineage.
I would wait until after cutover for anything that is not urgent to get right as soon as possible, such as broken URLs, email addresses, disappeared lists, and finding the new BZ smoothly. Also, fixing download pages and the contribution information, elimination of PayPal buttons, etc., seems more pressing as a priority. Changes for source download and build information for Apache OpenOffice might want to be introduced on the developer site or perhaps OOOUSER wiki, with the obsolete material on OpenOffice.org changed to portal to those areas. So perhaps rerouting could be introduced on the staging site for when cut-over happens. Of course, no downloads and build instructions should be encouraged this way until the IP Clearance has been completed. - Dennis -----Original Message----- From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] Sent: Thursday, November 24, 2011 01:10 To: ooo-dev@incubator.apache.org Subject: Re: Rationalizing two OpenOffice websites On 11/23/11 5:55 PM, Kay Schenk wrote: > +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". i also have thought about the api page and i would like to support it in the future as well. Because it provides some useful stuff for macro, extension developers. But maybe in a simplified and reduced form. things i would i would like to keep - API reference - C++/Java UNO Runtime reference - search features into the different reference documentation as well as the Developer's Guide - links to the SDK - link to the API wiki pages Most of the content will i move into the wiki as soon as possible. I would really like to work with you or somebody else who knows the Apache framework better then i to rework the API page. It would be really helpful if we can find an easy way to update the generated reference docu without checking in thousands of files. extensions.openoffice.org points today already in the wiki and i would like to redirect this page today to the api side. And in the future we can hopefully reactivate this page for an extension repository. And hopefully templates.openoffice.org for templates ;-) Juergen > > 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. >> > > >
