openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
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<>  wrote:
>> Am 02.07.11 23:41, schrieb Kay Schenk:
>>   OUCH! see below...
>>> On Sat, Jul 2, 2011 at 12:57 PM, Dave Fisher<>
>>>   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
>>>> Several of us have been surveying the existing website on
>>>> several wiki pages mostly linked to from:
>>>> With over 140 "projects" in, 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/<>is
a good and clear
>>>> way to start - and pretty much fits the structure on
>>>> 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 or stay on the
>>>> successor
>>>> http://*
>>>> Projects have "webcontent" and/or "wiki" content. On openoffice.orgthere
>>>> is a generally consistent look. There are exceptions which are marketing
>>>> sites like The difference is glaring because
>>>> that is the first big button on the main site.
>>>> Webcontent is available via svn - "svn co
>>>> 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....
>>> 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:
>>>   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:
> 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?


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.


View raw message