From owner-freebsd-doc@FreeBSD.ORG Thu Feb 23 17:55:25 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 2A58E16A420 for ; Thu, 23 Feb 2006 17:55:25 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: from av9-1-sn3.vrr.skanova.net (av9-1-sn3.vrr.skanova.net [81.228.9.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 110D743D48 for ; Thu, 23 Feb 2006 17:55:24 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 66D133812A; Thu, 23 Feb 2006 18:55:21 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 57C6638100; Thu, 23 Feb 2006 18:55:21 +0100 (CET) Received: from t3o55p73.telia.com (t3o55p73.telia.com [62.20.171.73]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id B97F137E44; Thu, 23 Feb 2006 18:55:16 +0100 (CET) From: Joel Dahl To: Murray Stokely In-Reply-To: <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> <20060222174523.GB64282@freebsdmall.com> Content-Type: text/plain Date: Thu, 23 Feb 2006 18:53:09 +0100 Message-Id: <1140717189.681.22.camel@dude.automatvapen.se> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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: Thu, 23 Feb 2006 17:55:25 -0000 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