5:57 p.m.
We've touched upon the idea of retiring fedora.redhat.com and putting
all of our content work on fedoraproject.org. Here are the salient
points, as I grok them:
* f.r.c is a static page or three that gives an appropriate message
and/or redirect to fp.o
* The build system that makes the /docs portion work needs to be i)
ported over or ii) rewritten in Python.
* Could we have the PHP building done inside a firewall and content
grabbed from another CVS repo by fp.o/docs? As an interim solution
until the includes are Pythonified.
* Rewriting of content on f.r.c can happen concurrently with figuring
out how to move over to fp.o.
* What about _not_ having the Wiki be the front page to fp.o? Then we
could have free reign with design. It can have a newsfeed section or
two to keep things lively, but even a better splash page than what we
have until the $PYTHON_CMS arrives from the sky.
Ready or not ...
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
8:37 p.m.
* The build system that makes the /docs portion work needs to be i)
ported over or ii) rewritten in Python.
Where is it right now? Can I get a look at it?
* Could we have the PHP building done inside a firewall and content
grabbed from another CVS repo by fp.o/docs? As an interim solution
until the includes are Pythonified.
yes.
* What about _not_ having the Wiki be the front page to fp.o? Then
we
could have free reign with design. It can have a newsfeed section or
two to keep things lively, but even a better splash page than what we
have until the $PYTHON_CMS arrives from the sky.
hehe. So about a month ago gdk pinged me on irc and said 'we need to
make the front page of fedoraproject.org the wiki frontpage.' So I said
'okay, lemme make an edit'. Then I did that and it was done. So you want
it put back the other way? :)
As an alternative I could include:
http://moinmoin.wikiwikiweb.de/ParserMarket?action=AttachFile&do=get&...
in our wiki which would allow whomever wants to edit the wiki front page
to make it raw html instead of wiki language.
lemme know what you'd rather have.
-sv
1:40 a.m.
On Tue, 2005-11-15 at 21:37 -0500, seth vidal wrote:
> * The build system that makes the /docs portion work needs to be
i)
> ported over or ii) rewritten in Python.
Where is it right now? Can I get a look at it?
cvs.fedora:/cvs/fedora/web/
html --> HTML, head replaced w/ PHP includes
include --> included bits
config --> tells how to setup a sandbox
scripts --> where the magic happens, including:
/docbookhtml2php.py
/dotphp2dothtml.sh
> * Could we have the PHP building done inside a firewall and
content
> grabbed from another CVS repo by fp.o/docs? As an interim solution
> until the includes are Pythonified.
yes.
OK, you can actually just use the existing system and rsync off the
built content. It is rendered into static pages hourly. PHP is not
used to deliver dynamic content in real time.
> * What about _not_ having the Wiki be the front page to fp.o?
Then we
> could have free reign with design. It can have a newsfeed section or
> two to keep things lively, but even a better splash page than what we
> have until the $PYTHON_CMS arrives from the sky.
hehe. So about a month ago gdk pinged me on irc and said 'we need to
make the front page of fedoraproject.org the wiki frontpage.' So I said
'okay, lemme make an edit'. Then I did that and it was done. So you want
it put back the other way? :)
As an alternative I could include:
http://moinmoin.wikiwikiweb.de/ParserMarket?action=AttachFile&do=get&...
in our wiki which would allow whomever wants to edit the wiki front page
to make it raw html instead of wiki language.
lemme know what you'd rather have.
Well, I wanted to bring this back up because of the problems we've had
using the Wiki as the front page, in terms of layout.
It was definitely the right move to make it the front page. It keeps it
within the engine of content delivery, which is not a CMS but is
starting smell like one. The html.py could also be a good idea, same
idea of all-one back-end with more flexibility.
I'll let Patrick weigh in here, as one person who has been feeling this
pain.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
1:42 a.m.
Hi
It was definitely the right move to make it the front page. It keeps
it
within the engine of content delivery, which is not a CMS but is
starting smell like one. The html.py could also be a good idea, same
idea of all-one back-end with more flexibility.
I'll let Patrick weigh in here, as one person who has been feeling this
pain.
We talked about this on #fedora-wiki before and Patrick wanted the html
plugin available in fedoraproject.org to design the frontpage in html if
necessary. So thats the solution preferred now.
regards
Rahul
2 a.m.
2005/11/16, Rahul Sundaram <sundaram(a)redhat.com>:
We talked about this on #fedora-wiki before and Patrick wanted the
html
plugin available in fedoraproject.org to design the frontpage in html if
necessary. So thats the solution preferred now.
Can I assume that this static html page doesn't need translation?
--
bbbush ^_^
2:16 a.m.
Yuan Yijun wrote:
2005/11/16, Rahul Sundaram <sundaram(a)redhat.com>:
>We talked about this on #fedora-wiki before and Patrick wanted the html
>plugin available in fedoraproject.org to design the frontpage in html if
>necessary. So thats the solution preferred now.
>
>
>
Can I assume that this static html page doesn't need translation?
--
bbbush ^_^
I dont see any reason to assume that. Translation of all the information
provided within the fedoraproject.org would be ideal.
regards
Rahul
7:13 a.m.
On Wed, 2005-11-16 at 13:12 +0530, Rahul Sundaram wrote:
Hi
>It was definitely the right move to make it the front page. It keeps it
>within the engine of content delivery, which is not a CMS but is
>starting smell like one. The html.py could also be a good idea, same
>idea of all-one back-end with more flexibility.
>
>I'll let Patrick weigh in here, as one person who has been feeling this
>pain.
>
>
We talked about this on #fedora-wiki before and Patrick wanted the html
plugin available in fedoraproject.org to design the frontpage in html if
necessary. So thats the solution preferred now.
Did anyone ever ask me about adding the html plugin to moin?
It's funny reading about these desired items for moin that no one
mentioned.
-sv
7:18 a.m.
Hi
Did anyone ever ask me about adding the html plugin to moin?
It's funny reading about these desired items for moin that no one
mentioned.
Well now you know! but seriously this list was created for such
discussions to be communicated and discussed in a more open manner.
regards
Rahul
4:58 a.m.
Karsten Wade wrote:
On Tue, 2005-11-15 at 21:37 -0500, seth vidal wrote:
>> * The build system that makes the /docs portion work needs to be i)
>> ported over or ii) rewritten in Python.
>>
> Where is it right now? Can I get a look at it?
>
cvs.fedora:/cvs/fedora/web/
html --> HTML, head replaced w/ PHP includes
include --> included bits
config --> tells how to setup a sandbox
scripts --> where the magic happens, including:
/docbookhtml2php.py
/dotphp2dothtml.sh
>> * Could we have the PHP building done inside a firewall and content
>> grabbed from another CVS repo by fp.o/docs? As an interim solution
>> until the includes are Pythonified.
>>
> yes.
>
OK, you can actually just use the existing system and rsync off the
built content. It is rendered into static pages hourly. PHP is not
used to deliver dynamic content in real time.
>> * What about _not_ having the Wiki be the front page to fp.o? Then we
>> could have free reign with design. It can have a newsfeed section or
>> two to keep things lively, but even a better splash page than what we
>> have until the $PYTHON_CMS arrives from the sky.
>>
> hehe. So about a month ago gdk pinged me on irc and said 'we need to
> make the front page of fedoraproject.org the wiki frontpage.' So I said
> 'okay, lemme make an edit'. Then I did that and it was done. So you want
> it put back the other way? :)
>
> As an alternative I could include:
>
http://moinmoin.wikiwikiweb.de/ParserMarket?action=AttachFile&do=get&...
> in our wiki which would allow whomever wants to edit the wiki front page
> to make it raw html instead of wiki language.
>
> lemme know what you'd rather have.
>
Well, I wanted to bring this back up because of the problems we've had
using the Wiki as the front page, in terms of layout.
It was definitely the right move to make it the front page. It keeps it
within the engine of content delivery, which is not a CMS but is
starting smell like one. The html.py could also be a good idea, same
idea of all-one back-end with more flexibility.
I'll let Patrick weigh in here, as one person who has been feeling this
pain.
- Karsten
Yes, having raw HTML abilities would probably give us most of what we
need to make a nicer FrontPage. My other concern has been some of the
issues created by the layout when the viewport is resized. Along with
raw HTML, some edits to the CSS might be needed to solve those. If that
is the case, I can work with Hrishi to resolve those as we find them.
It might take a little bit of work, but I'm sure we can get the wiki to
do the kind of FrontPage we're looking for.
It would be nice to keep the front page on the wiki for the sake of
consistency and management. If we are unable to produce an adequate
front page using the wiki, then I would of course have no objections to
an alternative solution. Really, I favor keeping the number of
different technologies we are using to a minimum, but we will probably
not be able to get everything in the wiki.
As we start wanting to add more dynamic capabilities to the front page,
we will either have to start producing modules for MoinMoin or we'll
have to use an alternative technology. Since MoinMoin has most of
fedoraproject.org's content, it makes sense to try first to make it do
what we need, and only fall back to other options where required. I
don't think it is a good idea to apply too many patches to MoinMoin for
manageability reasons, but producing modules that can be dropped in
makes sense. See the bottom of
http://fedoraproject.org/wiki/HelpOnMacros for more on adding plugins to
MoinMoin.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
7:21 a.m.
Yes, having raw HTML abilities would probably give us most of what
we
need to make a nicer FrontPage. My other concern has been some of the
issues created by the layout when the viewport is resized. Along with
raw HTML, some edits to the CSS might be needed to solve those. If that
is the case, I can work with Hrishi to resolve those as we find them.
It might take a little bit of work, but I'm sure we can get the wiki to
do the kind of FrontPage we're looking for.
Then why all the discussion? Get the page designed and written in html
that you like and just ask for the html parser module.
As we start wanting to add more dynamic capabilities to the front
page,
we will either have to start producing modules for MoinMoin or we'll
have to use an alternative technology. Since MoinMoin has most of
fedoraproject.org's content, it makes sense to try first to make it do
what we need, and only fall back to other options where required. I
don't think it is a good idea to apply too many patches to MoinMoin for
manageability reasons, but producing modules that can be dropped in
makes sense. See the bottom of
http://fedoraproject.org/wiki/HelpOnMacros for more on adding plugins to
MoinMoin.
What are these other features that will be needed? And what dynamic
capabilities do you want to add to the front page?
Maybe I've missed something but has all this been discussed somewhere
else?
-sv
12:18 p.m.
On Wed, 2005-11-16 at 08:21 -0500, seth vidal wrote:
What are these other features that will be needed? And what dynamic
capabilities do you want to add to the front page?
Maybe I've missed something but has all this been discussed somewhere
else?
Mainly IRC or various fedora-*-lists, as side bar discussions.
As Rahul said, we knew we were doing it the wrong way. Now we can
discuss, decide, and get stuff in your queue v. tackling you on IRC. :)
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
10:21 a.m.
Well, I wanted to bring this back up because of the problems
we've had
using the Wiki as the front page, in terms of layout.
It was definitely the right move to make it the front page. It keeps it
within the engine of content delivery, which is not a CMS but is
starting smell like one. The html.py could also be a good idea, same
idea of all-one back-end with more flexibility.
I'll let Patrick weigh in here, as one person who has been feeling this
pain.
So are we decided we want html.py as a parser module and then the front
page can be whatever?
-sv
10:46 a.m.
seth vidal wrote:
> Well, I wanted to bring this back up because of the problems
we've had
> using the Wiki as the front page, in terms of layout.
>
> It was definitely the right move to make it the front page. It keeps it
> within the engine of content delivery, which is not a CMS but is
> starting smell like one. The html.py could also be a good idea, same
> idea of all-one back-end with more flexibility.
>
> I'll let Patrick weigh in here, as one person who has been feeling this
> pain.
>
So are we decided we want html.py as a parser module and then the front
page can be whatever?
-sv
I think that's the idea. HTML will allow quite a bit more flexibility
than what we have now. It would also be nice if we could get the
sidebar-hiding patch in. As we prepare to add external news feeds or
other dynamic information, we may need to add other small plugins to get
the job done, but hopefully we can avoid using too many other patches.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
11:25 a.m.
I think it's a given at some point that we're retiring f.r.c. But there's
still work to be done maintaining it, for now.
What we MUST do:
1. Identify static content that should not change much. Why? Because we
need to translate it into every language on Earth. The more this content
changes, the more difficult that will be to achieve realistically.
2. Actually translate it.
These first two items needed to happen a long time ago. They're happening
now. For right now, they're happening on f.r.c. Long-term, I don't care
where this content goes, or what form it's maintained in -- so long as
it's fairly static and easily translatable.
And then:
3. Better design.
4. Figure out where this content will live.
The problem we've been having is that we've been waiting for 4. to be
resolved before working on 1. and 2. We're not doing that anymore.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
On Wed, 16 Nov 2005, Patrick Barnes wrote:
seth vidal wrote:
>> Well, I wanted to bring this back up because of the problems we've had
>> using the Wiki as the front page, in terms of layout.
>>
>> It was definitely the right move to make it the front page. It keeps it
>> within the engine of content delivery, which is not a CMS but is
>> starting smell like one. The html.py could also be a good idea, same
>> idea of all-one back-end with more flexibility.
>>
>> I'll let Patrick weigh in here, as one person who has been feeling this
>> pain.
>>
>
> So are we decided we want html.py as a parser module and then the front
> page can be whatever?
>
> -sv
>
>
>
I think that's the idea. HTML will allow quite a bit more flexibility
than what we have now. It would also be nice if we could get the
sidebar-hiding patch in. As we prepare to add external news feeds or
other dynamic information, we may need to add other small plugins to get
the job done, but hopefully we can avoid using too many other patches.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
6753
days inactive
6754
days old
websites@lists.fedoraproject.org
13 comments
6 participants
participants (6)
-
Greg DeKoenigsberg -
Karsten Wade -
Patrick W. Barnes -
Rahul Sundaram -
seth vidal -
Yuan Yijun