On Jul 2, 2011, at 5:26 PM, Raphael Bircher wrote: > Am 03.07.11 01:30, schrieb Kay Schenk: >> On Sat, Jul 2, 2011 at 3:41 PM, Raphael Bircher<r.birc...@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<dave2w...@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. > Ther is a webbased CMS on Apache at http://cms.apache.org . Well it's not a > rich CMS, but you can edit a page without using SVN and Command Line. I think > cause the performance, a static page as main page is not a bad idea. Markdown > is much easier as html and as I said above, you don't have to deal with svn > for normal maintenance. > > The problem that not all content developer has access to the Apache CMS is > true. The problem is, that the ASF dosn't make a difference between Content > Developer and Core Developer. At ASF that's the same status. Become a > Commiter it's not a fast proces.
You have to show sustained contribution. Patches and presense are noticed by the PPMC who review and commit the work of non-commiter developers. Often this comes at the point where the reviewing committers would rather have the contributor do it themselves. This is what takes time. > First you have to fill ICLA, then you have to be voted in by PPMC, and finaly > you have to wait for the apache account. The main purpose of the ooo-private list is for the PPMC to discuss various individuals, vote, and only once a new committer has an account will there be a welcome email on ooo-dev. > At the OOo Project you have only ask a Project Lead for content defeloper > right. Therefor you have access to the whole site at Apache OOo. Regards, Dave > > Greetings Raphael > > -- > My private Homepage: http://www.raphaelbircher.ch/
