[fab] Legal contact policy and incentives for contributors

Patrick W. Barnes nman64 at n-man.com
Thu Jul 13 12:59:21 UTC 2006


On Thursday 13 July 2006 03:32, Rahul <sundaram at fedoraproject.org> wrote:
> Patrick W. Barnes wrote:
> > The pages on fedora.redhat.com are current, and that's a better way to
> > greet visitors than a "This page has moved..." page.  fedora.redhat.com
> > is also our current home for static content, and there's not much reason
> > in trying to disable it when some pieces, like /docs, can't yet be moved.
>
> /docs is the only major holdout currently and we are already working on
> moving that over.

It's not the only holdout, but it is the largest one.

>
> > Yes, we need a way to set up automatic redirects, but automatic redirects
> > are not compatible with the current fedora.redhat.com infrastructure. 
> > Once fedora.redhat.com doesn't need to serve *any* of the current
> > content, including /docs, we can break it in whatever ways are needed to
> > move it to an alternative system and get automatic redirects in place for
> > everything.
>
> I dont quite get this. How are we going to get automatic redirects in
> fedora.redhat.com at any point at all if the infrastructure is not
> compatible? Are we going to change the infrastructure?

It's an option, but only once the current infrastructure is useless.

>
> > Whether we have automatic redirects or not, we will not get rid of our
> > static content, point users to a wiki location, recreate our static
> > content, and create an additional redirect from the wiki to that new
> > static content.
>
> Its not as difficult as you make it sound. "static content" can just be
> wiki pages with ACL's. The number of static pages in fedora.redhat.com
> is probably just a dozen and some of which are already duplicated in the
> wiki.

I'm not saying it's extremely difficult, I'm saying we don't want to treat our 
users like ping-pong balls when we'll be able to achieve a near-perfect 
solution if we're just patient a little longer.

>
>    The
>
> > static content will be permanently housed on the Plone site, and we don't
> > want to redirect users anywhere until we can redirect them there.
> >
> > I'll admit that the current state of fedora.redhat.com isn't ideal, but
> > it already points to the wiki for most purposes, and keeping just like it
> > is until we can move in our better technological solutions isn't going to
> > hurt anything.
>
> Actually it does. There a number of old pages that google finds confuses
>   users like Thorsten pointed out and having the website so spartan is
> bad. It also splits traffic between fedora.redhat.com and
> fedoraproject.org. As long as we have two different websites for the
> same thing, we are bound to do redundant work. We keep talking about
> setting up the plone page but I dont see anyone working on it (other
> than a stock fpserver.fedoraproject.org) and I dont know enough about
> plone to do things myself. So how are we going to progress on this? We
> need a reasonable timeframe and being struck with no movement on plone
> is not a option.
>

The old stragglers from before the fedora.redhat.com revamp can (and must) be 
replaced with manual redirects, but that's a separate issue entirely.  I 
still feel that the change of locations during the revamp was a folly.  Of 
course, if we completely knock out that infrastructure and get something in 
place that enables automatic redirects, we can redirect all pages, old and 
new, to appropriate Plone locations.

http://fedoraproject.org/wiki/Websites/PloneToDo

http://fedoraproject.org/wiki/DocsProject/PloneIssues

I don't think content for the Plone site is going to be a real problem 
anymore.  Once the other issues are resolved, I think we'll be able to move 
Plone into place quickly.  We can take care of further enhancement as we go.

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

http://www.n-man.com/

LinkedIn:
http://www.linkedin.com/in/nman64

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/
-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20060713/4555110c/attachment.bin 


More information about the advisory-board mailing list