incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: Website Content plus Look and Feel Improvements
Date Sun, 03 Jul 2011 00:21:46 GMT
Am 07/03/2011 01:30 AM, schrieb Kay Schenk:
> On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher<r.bircher@gmx.ch>  wrote:
>
>> Am 02.07.11 23:41, schrieb Kay Schenk:
>>
>>   OUCH! see below...
>>>
>>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<dave2wave@comcast.net>
>>>   wrote:
>>>
>>>   Yesterday I got tired of the look of people.mdtext in the project site.
>>>> It
>>>> was so 1990s. So, I've improved the look via css and adding defined
>>>> widths.
>>>> I guess I am volunteering for the item on
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Help+Wanted<https://cwiki.apache.org/confluence/display/OOOUSERS/Help+Wanted>
>>>>
>>>> Several of us have been surveying the existing openoffice.org website on
>>>> several wiki pages mostly linked to from:
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Site-PPMC-Plan<https://cwiki.apache.org/confluence/display/OOOUSERS/Site-PPMC-Plan>
>>>>
>>>> With over 140 "projects" in openoffice.org, it will be important to
>>>> agree
>>>> to a mapping which reduces the granularity by more than an order of
>>>> magnitude. The page http://projects.openoffice.**org/<http://projects.openoffice.org/>is
a good and clear
>>>> way to start - and pretty much fits the structure on
>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>>> Project+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning>
>>>>
>>>>
>>>          • Product Development
>>>>         • Extension Development
>>>>         • Language Support
>>>>         • Helping Users
>>>>         • Distribution
>>>>         • Promotion
>>>>
>>>> I think that these groupings will help us easily have a rule about which
>>>> projects end up on http://openoffice.apache.org/ or stay on the
>>>> successor
>>>> http://*.openoffice.org/.
>>>>
>>>> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
>>>> is a generally consistent look. There are exceptions which are marketing
>>>> sites like http://why.openoffice.org/. The difference is glaring because
>>>> that is the first big button on the main site.
>>>>
>>>> Webcontent is available via svn - "svn co
>>>> https://svn.openoffice.org/**svn/${project}~webcontent<https://svn.openoffice.org/svn/$%7Bproject%7D%7Ewebcontent>${project}"
(Thanks
>>>> Marcus Lange)
>>>>
>>>>
>>>   Some projects are huge and others small. I downloaded several:
>>>>
>>>>   I think "infrastructure" which is the project for all aspects dealing
>>> with
>>> the development of the old web site itself could be thrown out completely,
>>> since, ta da, here we are in a new environment. And, much of that is VERY
>>> old. Ditto for much of the "download" area which goes back to the
>>> non-mirrors age.
>>>
>> The problem is, that we have many dead pages on the SVN. At Collabnet we
>> haven't the right to delete pages from the CVS. So many many unused site is
>> still on the SVN but you won't find it over the OOo webpage.
>>
>>   It might be useful to take the domains list....
>>>
>>>   https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> OpenOffice+Domains<https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains>
>>>
>>> and see what can be combined into your suggested categories below.  Maybe
>>> we
>>> could start something like this as a seperate item off the "To Do" list on
>>> the OOo-sitemap page. Oddly, some of these actual "virtual domains" are
>>> really part of the main website -- web~webcontent.
>>>
>> I have already done a sitemap for all projects. It's only 4 month old. I do
>> this sitemap for the kenai migration. I will upload the list. It's a line
>> separated textfile.
>>
>>   The following page needs more fleshing out:
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**OOo-Sitemap<https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap>
>>>
>>>
>>>
>>>   wave@minotaur:~/ooo-test$ ls -1
>>>> development
>>>> documentation
>>>> download
>>>> projects
>>>> www
>>>>
>>>> The size is 2.7GB.
>>>>
>>>> It would be good to come up with a scripted way to convert existing
>>>> webcontent to either mdtext, an altered html, or specialized javascript
>>>> and
>>>> css. It is likely we can adapt the content and use the Apache CMS to wrap
>>>> a
>>>> standard skeleton.
>>>>
>>>>   Yes we need a script, but I think the Script can only do basic work. The
>> OOo Page is not so easy as it looks. Ther are many special features on the
>> kenai framework, and a load of JavaScript. I agree with Kai that we have to
>> be verry carefull.
>>
>> Greatings Raphael
>>
>> --
>> My private Homepage: http://www.raphaelbircher.ch/
>
>
> OK, a totally different thought/approach.
>
> I think it might be easier in the long run to migrate the entire current OOo
> site in total (well except for maybe a few areas/projects) and deal with the
> revamping/reorg on a longer term basis -- culling out a bit at a time.
>
> I think trying to deal with this NOW will considerably slow site migration
> down, maybe even prevent it altogether and will considerably upset existing
> users I think.
>
> The biggest problem with this alternate approach, well really ANY approach,
> is that folks that formerly had commit rights to sites, won't, because they
> aren't committers. And now, with the (somewhat) recent migration to kenai,
> it's a bit difficult to tell what was going on before that.
>
> We should definitely think long term about migrating nearly all project home
> pages to a wiki for easier maintenance. I think much of this had already
> happened in actuality. People didn't want to deal with cvs/svn or anything
> even remotely "techie" to participate.
>
> Obviously the BIGGEST change is what people now see for the projects on the
> site (esp the language areas), but many of those current enhancements just
> recently emerged with kenai. We can scale back this listing.
>
> Thoughts?

+1

I also think that a (nearly) complete migration makes most sense. Then 
we can take the time to delete unwanted/unnecessary stuff and take the 
reamining into the Wiki if not already done.

Marcus

Mime
View raw message