cvs commit: www/share/sgml includes.navdevelopers.sgml

[Murray Stokely]

On Wed, Feb 22, 2006 at 03:04:11PM +0100, Joel Dahl wrote:
> > Is there individual content that is in internal that you think should
> > be made more visible?  The release engineering schedules, todo lists,
...
> > and procedures used to live in internal but migrated to the public
> > areas when I realized the much broader audience interested in that
> > material.  It is likely that other material may also be due for a
> > migration into more public areas.
> 
> I disagree.

Please answer my question above.  What content do you want made more
prominent?  Half of the content in internal/ is already available more
directly through other second level pages.  "Internal Pages" doesn't
mean anything and is a very confusing link for anyone visiting the web
site.  It tells you nothing about what will actually be contained on
that page.

> 1.  Stating that the internal pages should be "completely impossible" to
> find is absurd.  We've been linking to them from our public site for
> years and we also have a couple of old newsletters linking directly to
> them.

Then perhaps there is a misuinderstanding about the word "Internal".
It is not absurd that a page marked "internal" should be impossible to
reach "externally".  That is exactly what I would expect.  Seeing a
link that says "internal" almost looks like the site has been owned.
It is a weird link to see prominently on the menus.

I agree the content is in practice more open that I was aware of over
the past 7 years.

> 2.  I consider our internal pages a resource for our developers, but
> what happens when our developers cannot reach it?  The resource becomes
> useless, which is a step backwards for the project.  I've heard several
> developers complain about how hard the internal pages are to find, and
> I'm not even sure everyone knows about them at all. This is bad, bad,
> bad.

I agree we should make developer information accessible to those that
need it, which is why I'm curious exactly what information in
internal/ you are most concerned about so we can find a better way
than a confusing and redundant 'Internal Pages' link everywhere to
make it visible.

Every new committer email communication from the commit-bit granting
body and/or mentor should contain a pointer to the internal area of
the website and the new committer guide.

> 3.  If we want something secure which is developers-only, then we should
> password protect it (or introduce some other system).  Anyone can read
> our CVS logs, so just about anyone with some interest in our website
> infrastructure can look at those pages.  Google knows about them too, no
> matter how secret you think they are.

I think we should maybe robot parts of the area out (with ftp/www
statistics) but it doesn't bother me that really dedicated people can
find the data.  There is a big leap from being publically available to
people who search for it and having large links to it all over the
site.  It is a stronger endorsement that we think the numbers are more
accurate.

> 4.  ...but hey, our internal pages doesn't contain the secret master
> plan for world domination.  This projects needs to open up and show what
> a great team of talented people we are.  I consider adding a link to our
> internal pages a step in the right direction.

It doesn't belong on the side menu on every page.  It is way too
obscure of a topic to pollute the menus in that way.  A single link on
the developers page would be much better.

We do not want to go down the path of our last website of adding lots
of confusing redundant links (most of the internal/ links are already
available through other more direct parts of the website).

	  - Murray