Hi. I decided to put this thread aside for the last several days and have just reviewed it (and the ones is spawned) all at once. After thinking about the various comments, some observations (none completely original although my summary may be different from what others have said in some cases) and a suggestion: (1) At this stage in the process, [re-]design by committee and nit-picking are probably not helpful, no matter how interesting and engaging they might be. Bug reports to the IETF list probably aren't either. On the other hand, to the extent to which a large collection of 404s or failures on validation or accessibility tests show up, that goes beyond bugs and reflects badly on the design and/or implementation processes (for which see below). (2) We know there are at least two different audiences for an IETF web page -- participants trying to get work done and and people trying to find out what the IETF is about. Those may further subdivided: there is a difference between newcomers interested in better understanding and eventual participation in the IETF's work, policymakers trying to understand IETF and its relationship to policy development and work going on elsewhere, and managers and others trying to make decisions about IETF (or maybe even ISOC) support, permission of staff members to participate and travel, etc. Similarly, there are people trying to find out what the IETF is doing in a particular topic area and how they can get involved with it and those whose technical interest in the IETF is more general or more about the Intere6t rather than a specific protocol or cluster of protocols. I think we all understand that it is impossible to optimize for all of those audiences and sub-audiences at once, but it is not clear that the current site reflects that understanding. For example, my guess is that the IETF's interactions with IGF (such as they are) are probably of significant interest to only one of those subgroups and, for it, the explanation is probably not nearly adequate. I believe that is a symptom, not a particular problem that, once solved, goes away. (3) Whatever we do should reflect IETF values about quality, security, etc. If FaceOogAppAzonBaba conclude that they should respond to their audiences and marketing personnel by web sites with lots of animation, rotating pictures and videos, extensive use of CSS and JS and links off to other domains, etc., it may make the practices common and even what lots of people are used to, but, while we should be aware of that in our design, it doesn't make those practices "good" (much less "best") or what we should be doing. Given the concerns about JavaScript and the obvious risks of links to non-IETF sites, I think the designers should be required to consider every instance of either as a tradeoff and to be ready to explain the importance of each one to the community, not just to move freely ahead on each because they think they are pretty and/or effective in reaching or impressing some audience. Given some of the other comments, if there had not been an earlier beta and comments on it, and if it were clear that those comments were reflected in the later version (or the reasons why not explained if the issues were even vaguely substantive or strategic), I would not be writing this note. But it appears to me that the spirit of many of the earlier comments was not accommodated. So, assuming two assumptions are correct, a suggestion. The first of those assumptions is that the IETF still makes decisions about policy and strategy (not just narrowly technical issues) by rough consensus, not by appointing people to make those decisions for us. I'm not talking about the details of web page design, but I am talking about whether security and/or accessibility is important in our public-facing materials, whether we want to have a "marketing" stance at all and whether the "work" pages and goals should be subsidiar6 to it or vice versa. If our leadership, or those who whom they have chosen to delegate authority, don't believe the community is able to understand those issues and make intelligent tradeoffs about them, I just hope the Nomcom is listening carefully. The second is that there are conditions under which it is appropriate to say "well, this isn't working" and go back to design principles and new approaches. A colleague suggested 50-odd years ago that software modules that demonstrated a large number of bugs should be treated as deeply defective and reimplemented from scratch, preferably by different people to lower the risk of making the same mistakes a second time, after the goals and design were carefully reviewed. One has to wonder whether the process that produced this general approach needs review and evaluation if, after several iterations, the new site is still as far from meeting the expectations of the community as the length and number of comments in these threads would suggest .. and to wonder whether the collection of bad links from the new pages, validation failures, etc., are supportive of the hypothesis that we have the right design and implementation teams (Ned's recent comments about understanding and recognizing when work is not good are directly relevant here, as is the question of whether this is a situation we should be trying to patch our way out of). So, can we go back to the design goals and mission given to the folks who did this, get it posted, and see if there is rough consensus, now that we have seen what is supposed to be an implementation according to those goals and see if we still have (at least rough) consensus about those goals? Can we ask the question of how well the implementation matches those goals (and any other goals that we might add in retrospect? If the answers are as negative as I think these threads suggest, can we have an open discussion about what to do next, rather than another set of back-room decisions? And can we be sure that the option of going with a different team is on the table, if only because the current team, having spent a lot of time on this effort, is naturally going to be more inclined to patch than to start rethinking? It need not be the choice and, given work done already, I hope we don't need it, but it seems to me to be important that it be possible. best, john