[OpenAFS] New OpenAFS website proposal.

[Jakub Witkowski]

2010/12/7 Derrick Brashear <shadow@gmail.com>:
> Sorry for the radio silence the last few days
>
I feel especially guilty for it - I got caught up in other projects.


> On Sun, Nov 28, 2010 at 1:45 PM, Jakub Witkowski <jpw@jabster.pl> wrote:
>> 2010/11/26 Jason Edgecombe <jason@rampaginggeek.com>:
>>> On 11/26/2010 01:55 PM, Steve Simmons wrote:
>>>>
>>>> In re plone vs this-that-the-other, Xwiki vs. Ywiki, etc -
>>>>
>> [...]
>>>
>>> One challenge is that we don't have a site manager.
>>>
>>> Here are the authors of commits to the web site since 2009-01-01
>>> Derrick Brashear (58)
>>> Jason Edgecombe (21)
>>> Jeffrey Altman (16)
>>> Russ Allbery (2)
>>> Simon Wilkinson (1)
>>>
>>> Derrick and Jeff's commits mostly deal with releases, and mine mostly d=
eal
>>> with the newsletter.
>>>
>>> Volunteers for site manager are welcome.
>>>
>>
>> I am willing to take that task up.
>>
>> That said, let me clarify my current position.
>> 1. Yes, documentation should be kept in git.
>> =C2=A0 My initial mistake was caused by that I let the revision table at
>> the start of User Guide to colour my opinion; simply seeing that,
>> according to the revision table on first page, last update happened
>> more than ten years ago, made me thought that the website version of
>> it has never been actually touched up.
>
> Probably the tool that "emits" the documentation from git should write a
> correct revision table, and in this vein we illustrate some of the toolsm=
ithing
> we need.
>
I'm right in the middle of writing it! My current hurdle is to make
sensible parsing of Docbook files since every Python tool for Docbook
seems to be focused on churning pdf, dvi or bunch of plain old HTML
files, which is not exactly what I need, since my goal is to represent
top level of hierarhy in objects other than "index at the top of the
page".

>> 2. I believe that using CMS, in long term, we can save time to those
>> central to the project - that is, those who usually have the least of
>> it to do things like adding new bits to the website.
>
> Might I propose a CMS that works not unlike Apple's iWeb, namely,
> that allows editing and "publishing" a site, rather than requiring specif=
ic
> software be installed on the server, might fit better what people
> expect here. And if for some reason we would end up in a situation
> where the toolchain becomes orphaned, we have the content in a form
> (HTML) that can be imported into a different solution.
>
Perhaps this would be a good solution. I never really considered that
angle, since my experience with this kind of tools has been limited to
Dreamweaver in times when php3 was new and, based on what I learned,
seemed to be an attempt to create lock-in in the web.

>> 3. While Plone is my personal favourite, I am willing to argue that; I
>> do not presume that this piece of software is best for all
>> circumstances.
>
> I'm not opposed to it, personally. I have no strong take at all.
> My desire to be able to "syndicate" our website by publishing into
> our own file system and thus serving it out of web servers
> worldwide to showcase the technology is really the only
> strong feeling whatever I have on the matter.
>
This could be approached from several angles. For example, there is a
tool that takes a plone site and emits HTML pages that represent
unauthenticated user's view of it.

>> 4. I am willing to put considerable time into making the website not
>> only "pretty" but also quite usable.
>
> Thank you.
>

Jakub.