From owner-freebsd-doc@FreeBSD.ORG Fri Feb 24 01:58:56 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 EA35216A422; Fri, 24 Feb 2006 01:58:55 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8722143D45; Fri, 24 Feb 2006 01:58:55 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 8FB5228DD; Thu, 23 Feb 2006 19:58:54 -0600 (CST) Date: Thu, 23 Feb 2006 19:58:54 -0600 To: Murray Stokely Message-ID: <20060224015854.GB16997@soaustin.net> 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> <1140717189.681.22.camel@dude.automatvapen.se> <20060223193450.GA54855@freebsdmall.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060223193450.GA54855@freebsdmall.com> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: doc@FreeBSD.org, Joel Dahl 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: Fri, 24 Feb 2006 01:58:56 -0000 On Thu, Feb 23, 2006 at 11:34:50AM -0800, Murray Stokely wrote: > I am saying that is not a good solution without additional changes > because that will lead to lots of different ways to get to the same > material and will clutter the navigation of the website. I'm not 100% sure that having different ways to get to the same material is really all that bad. However, I agree the navigation hierarchy should be as clean as possible. > My proposals below describe ways to make this material accessible in > fewer clicks than yours and with less clutter. I think we can all agree on these goals. > I want to add more direct links to the few useful items of information > there that are not already available, instead of making people click > through yet another layer to get to the policies documents and such > that you speak of. As the author of the last re-architecting of the main "internal" page let me say that I'm all for this. The work I did was IMHO necessary but insufficient. It pushed a few things down one level (good) but did not complete the refactoring (sigh). > Since there have never been links to this material from the main or > other second level pages I thought there were other cross-links from elsewhere in the site? > I propose linking to the content you want, such as "Policies for > FreeBSD Committers" prominently on the existing developer page. > [...] When you click on "developers" from the front page you > should get all information relevant for developers. Right now, it > takes you immediately to the in progress development projects, which > is too narrow. Some higher level information should be added to the > top of that page with information about policies for committers (as > you propose), and other information. The FreeBSD Development projects > can be pushed down further or made a third level page instead of the > second page prime link real estate of 'Developers' that it currently > occupies. If we change "Developers" to "Development" I think pushing the projects down makes more sense, and might shift the emphasis more towards the process and the product (of interest to users) than the people (primarily of interest to the people themselves). e.g. break the links up into who/what/where/when: Development -> release engineering (when) Development -> current projects (what) Development -> developer policies (who) Development -> development resources (where) The resources would probably only be of interest to current developers, but it _might_ be to prospective developers. (I know that I read through all those pages when I was figuring out if I wanted to get more involved.) The policies IMHO are _definitely_ of interest to prospective developers. As for the part about "obsolete/misleading information", again IMHO, that stuff just needs to be either deleted or stuffed onto a page saying "historical documents in need of updating." It makes the project look less active than it is (nothing is more stupid than seeing a web page referring to information from 2002 calling it "just released"). Yes, I am willing to do some work on pruning those things (and also projects/, which suffers from the same problem). Lastly, if there is information that truly needs to be internal to the project (I am not aware of any), then it shouldn't be in the www/ tree to start with, since anyone can cvs a copy of that tree. mcl