From owner-freebsd-doc@FreeBSD.ORG Wed Feb 22 17:45:23 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B7016A420; Wed, 22 Feb 2006 17:45:23 +0000 (GMT) (envelope-from murray@freebsdmall.com) Received: from mail.freebsdmall.com (69.50.233.168.ip.nectartech.com [69.50.233.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B10D43D46; Wed, 22 Feb 2006 17:45:23 +0000 (GMT) (envelope-from murray@freebsdmall.com) Received: by mail.freebsdmall.com (Postfix, from userid 2074) id 28DDC1D7497E; Wed, 22 Feb 2006 09:45:23 -0800 (PST) Date: Wed, 22 Feb 2006 09:45:23 -0800 From: Murray Stokely To: Joel Dahl Message-ID: <20060222174523.GB64282@freebsdmall.com> References: <200602211929.k1LJTTAH060389@repoman.freebsd.org> <200602211556.34034.jhb@freebsd.org> <20060222011622.GB11099@freebsdmall.com> <1140617051.681.35.camel@dude.automatvapen.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1140617051.681.35.camel@dude.automatvapen.se> X-GPG-Key-ID: 1024D/0E451F7D X-GPG-Key-Fingerprint: E2CA 411D DD44 53FD BB4B 3CB5 B4D7 10A2 0E45 1F7D User-Agent: Mutt/1.5.11 Cc: doc@FreeBSD.org Subject: Re: cvs commit: www/share/sgml includes.navdevelopers.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 17:45:23 -0000 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