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

[Joel Dahl]

On Wed, 2006-02-22 at 09:45 -0800, Murray Stokely wrote:
> 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.

How about everything?  There are several documents that are both
interesting and important for outsiders.  For example, I consider our
policy-documents very important, and they should be more visible to the
rest of the world, since this will contribute to a deeper public
understanding about how this project is being run.  We should encourage
people to familiarize themselfs with our traditions, standards, and
conventions, even if they haven't got a commit bit.

Please answer this question:  Why should we hide this information?

> > 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.

You keep repeating that this link is "confusing" and "weird".  I do not
share your opinion.  You can probably find a lot of websites on the
Internet that have internal pages open for anyone to look at.  Renaming
our internal pages to something else would only cause a lot of
confusion, especially for our developers.

> > 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.

See answer above.

> > 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.

This statement confuses me.  So, now you don't care if "really dedicated
people can find the data"?  Yesterday you claimed that this information
was "inappropriate for wide consumption" and that it should be
"completely impossible" to access.  Please explain yourself.

> > 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.

Adding a link to the developers page is equal to not having a link at
all, and you know that.  One link quickly disappears in that mess.
Perhaps this is the only solution, but I certainly don't like it.

> 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).

This is irrelevant.  We're talking about adding one single link, not
polluting the entire website with links.  I'm well aware of the problems
we had with the old website.

I'm afraid this will turn into a typical FreeBSD bikeshed, but this is
certainly not something I want.  I can present a solution to a problem,
and I received positive and encouraging feedback from developers when I
made the internal/ area easier to access.  I would like to re-add a link
to internal/ again, in some form.  Our internal pages are already
visible, so this cannot possibly hurt anyone.

I have plans on improving internal/, but they are on hold as long as
this matter is unresolved.

Peace.

-- 
Joel - joel at FreeBSD dot org