Documentation suggestion on documentation suggestions

I am new to Linux, and would like to participate in XEmacs documentation by pointing out items that a new user might stumble over, and which might be helped by additional documentation. I had actually missed most of the information in the Mailing Lists web page, which almost no amount of documentation could help, but this suggestion is meant to get more of the information near the top where it will be harder for dummies like me to miss, and to add some more helpful information. I hope that this will be the first of many suggestions related to documentation directed toward new users. Stephen J. Turnbull sent me the message attached below. On his advice, I am sending documentation suggestions to xemacs-beta. Here is my first suggestion, with items taken directly from his note labeled "ST:". To separate my suggestions from Stephen's, I have introduced some redundancy, which I assume will be removed if and when the suggestions are implemented. Add the new information in the attached message to the web pages starting with http://www.xemacs.org/Lists/index.html. More specifically: 1. In http://www.xemacs.org/Lists/index.html, Change the title and first two paragraphs to: ---------------------------------------------------------------------- XEmacs Mailing Lists and Newsgroup Several mailing lists and a newsgroup are available to facilitate development and discussion of XEmacs. These are essential to the development process of XEmacs. If you wish to participate effectively, you should subscribe or regularly review the archives of the relevant lists. ST: comp.emacs.xemacs is the main channel for user discussion. Although the developers participate irregularly, most simple configuration errors and "the defaults are stupid, how do I get it to work the way I want it to" questions are answered within hours by experienced users. xemacs-beta is the bug report/beta testers list. M-x report-xemacs-bug is addressed to xemacs-beta, and followup discussion takes place there. This is the most straightforward way to contact the developers, which is necessary any time you want to suggest a change in XEmacs. [Documentation] suggestions should go to xemacs-beta, End ST: since most documentation suggestions will not require extended discussion. ST: If you have an idea that requires extended discussion, that should go to xemacs-design. The remaining mailing lists are specialized, and some (xemacs-nt/xemacs-winnt in particular) are being phased out and integrated into xemacs-beta. End ST: Typically, user queries, suggestions, and discussion start with comp.emacs.xemacs, and migrate to xemacs-beta or xemacs-design when they get to the stage of a definite suggestion. ST: Currently, the typical workflow starts with a bug report from a user or a developer, which should be directed to xemacs-beta. A complex bugfix or a new feature, which requires more than minimal changes to XEmacs to implement, will then be discussed on xemacs-design. Any changes that arise from this discussion (or bugfixes arising directly from discussion on xemacs-beta) should then be submitted to xemacs-patches. Patches are vetted by the XEmacs Review Board. Review actions such as approval and veto of patches will be directed to xemacs-patches. However, all other discussion of patches under review should be directed to xemacs-design. ---------------------------------------------------------------------- 2. In the description of xemacs-beta in the descriptions of the various lists, and in the corresponding description in http://lists.xemacs.org/lists/listinfo/xemacs-beta/, replace Requests and proposals for non-bug-related changes do not belong on xemacs-beta, and should be sent to xemacs-design instead. by Proposals for documentation changes which are not expected to require much discussion should go to xemacs-beta. Other requests and proposals expected to result in non-bug-related changes do not belong on xemacs-beta, and should be sent to xemacs-design instead. Queries not expected to result in documentation or code changes should start in comp.emacs.xemacs or its mirror xemacs-news. Tom Frayne ---------------------------------------------------------------------- Begin forwarded message: Date: Fri, 17 Jan 2003 13:31:02 +0900 From: "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; To: Thomas Frayne <TomFrayne(a)sjpc.org&gt; Subject: Re: sumo tarball Thomas> Thanks. I'll follow that procedure. Which are the user Thomas> channels? xemacs-beta? xemacs-news? Others? comp.emacs.xemacs is the main channel for user discussion. Although the developers participate irregularly, most simple configuration errors and "the defaults are stupid, how do I get it to work the way I want it to" questions are answered within hours by experienced users. xemacs-news is an automatic gateway mailing list that has two functions. The first is to forward posts from mail to news and back, so the content is the same (subject to configuration error). The second is to arrange to archive the newsgroup with the rest of our channels. xemacs-beta is the bug report/beta testers list. M-x report-xemacs-bug is addressed to xemacs-beta, and followup discussion takes place there. This is the most straightforward way to contact the developers, which is necessary any time you want to suggest a change in XEmacs. If you have an idea that requires extended discussion, that should go to xemacs-design. The remaining mailing lists are specialized, and some (xemacs-nt/xemacs-winnt in particular) are being phased out and integrated into xemacs-beta. comp.emacs and some of the gnu.emacs.* are often useful, but you should avoid posting XEmacs-specific questions there. Thomas> Is comp.emacs.xemacs equivalent to xemacs-news as a Thomas> starting place, or do you prefer new documentation Thomas> suggestions to start in xemacs-beta? The doc suggestions should go to xemacs-beta. Most of the users on comp.emacs.xemacs will have already gotten past the point where it's useful, so it's noise to them. The need is in the distribution documentation. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.