Commit 5fff54a6 authored by adriana's avatar adriana

Import with [PATCH sourceforge] Initial HTML fixes, new PSGML site validation...

Import with [PATCH sourceforge] Initial HTML fixes, new PSGML site validation <uya31ubq5.fsf@ecf.teradyne.com>

--HG--
branch : adriana
parent 8bb4addc0495
%title%
XEmacs development team
%author%
john s jacobs anderson, stealing content from the FAQ
%main%
<H1>Who wrote XEmacs?</h1>
<P>XEmacs is the result of the time and effort of many people.
<h2>21.x releases</h2>
<P>In alphabetical order:
<UL>
<LI><A HREF="mailto:steve@altair.xemacs.org">Steve Baur</A>
<LI><A HREF="mailto:martin@xemacs.org">Martin Buchholz</A>
<LI><A HREF="mailto:galibert@pobox.com">Olivier Galibert</A>
<li><a href="mailto:jhar@tardis.ed.ac.uk">Jonathan Harris</a>
<LI><A HREF="mailto:jareth@camelot-soft.com">Jareth Hein</A>
<LI><A HREF="mailto:kyle_jones@wonderworks.com">Kyle Jones</A>
<LI><A HREF="mailto:kkm@kis.ru">Kirill Katsnelson</A>
<LI><A HREF="mailto:hniksic@srce.hr">Hrvoje Niksic</A>
<li><a href="mailto:andy@xemacs.org">Andy Piper</a>
<LI><A HREF="mailto:sperber@informatik.uni-tuebingen.de">Michael Sperber</A>
</UL>
<p><a href="Develop/otherDev.html">And many other contributors...</a>
<h2>19.16/20.x releases</h2>
<P>In alphabetical order:
<UL>
<LI><A HREF="mailto:steve@altair.xemacs.org">Steve Baur</A>
<br><img src="Images/steve.jpg" width="119" height="142"
alt="Portrait of Steve Baur"><br>
<LI><A HREF="mailto:martin@xemacs.org">Martin Buchholz</A>
<br><img src="Images/mrb.jpeg" width="110" heigth="131"
alt="Portrait of Martin Buchholz"><br>
<LI><A HREF="mailto:hniksic@srce.hr">Hrvoje Niksic</A>
<br><img src="Images/hniksic.jpeg" width="111"
width="126" alt="Portrait of Hrvoje Niksic"><br>
<LI><A HREF="mailto:acs@acm.org">Alvin Shelton</A>
<br><img src="Images/alvin.jpeg" width="151" height="170"
alt="Portrait of Alvin Shelton"><br>
</UL>
<h2>19.14 release</h2>
<p>In chronologic order:
<UL>
<LI><A HREF="mailto:cthomp@xemacs.org">Chuck Thompson</A>
<br><img src="Images/cthomp.jpeg" width="120" height="120"
alt="Portrait of Chuck Thompson"><br>
Chuck was Mr. XEmacs from 19.11 through 19.14, and is responsible
for XEmacs becoming a widely distributed program over the Internet.
<LI><A HREF="mailto:ben@666.com">Ben Wing</A>
<br><img src="Images/wing.jpg" width="120" height="120"
alt="Portrait of Ben Wing"><br>
<LI><A HREF="mailto:jwz@jwz.org">Jamie Zawinski</A>
<br><img src="Images/jwz.jpg" width="120" height="120"
alt="Portrait of Jamie Zawinski"><br>
Jamie Zawinski was Mr. Lucid Emacs from 19.0 through 19.10, the last
release actually named Lucid Emacs. Richard Mlynarik was crucial to
most of those releases.
<LI><A HREF="mailto:mly@POBox.com">Richard Mlynarik</A>
</UL>
<P>Along with many other contributors, partially enumerated in
the <strong>`About XEmacs'</strong> option in the <strong>Help</strong> menu of XEmacs.
<p><b>Source:</b> <a href="FAQ/">FAQ</a> item 1.2.1
%title%
How to Help
%author%
john s jacobs anderson
%main%
<h1>How to Help</h1>
<p>More detailed information is forthcoming, but in the short
term, if you'd like to help with the XEmacs development
effort, do the following:
<ol>
<li><a href="Download/index.html">Download</a> the latest
beta release, or (better) go to
<a href="http://cvs.xemacs.org">cvs.xemacs.org</a> and
follow the instructions to get an up-to-date CVS tree of
the XEmacs source.
<li><a href="Install/index.html">Install</a> it.
<li>Join the <a href="Lists/index.html">xemacs-beta</a> mailing list.
<li>Find bugs.
<li>Fix them.
<li>Submit patches to the <a href="Lists/index.html">xemacs-patches</a> mailing list.
</ol>
%title%
JOBS
%author%
ben wing; html-ized by jsja
%main%
<h1>XEmacs JOBS</h1>
<h4>Current version: 11/11/99<br>
Maintainer: Ben Wing
<a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a></h4>
<h1>XEmacs Review Board Members</h1>
<p>The XEmacs Review Board has the authority to approve or
veto any patch to XEmacs. Patches should be posted to
<a href="mailto:xemacs-patches@xemacs.org">xemacs-patches@xemacs.org</a>.
If someone vetoes your patch, you will receive e-mail from
them, stating the veto but also describing exactly why the
patch was vetoed, and how it should be changed in order to be
acceptable. To qualify for membership to the Review Board,
you should generally be someone who has put a lot of work into
developing XEmacs for a long enough period of time that you
are aware of the all of the basic ideas and issues in XEmacs
and the XEmacs community.
<p>The current members of the XEmacs Review Board are:
<ul>
<li>Andreas Jaeger <a href="mailto:aj@xemacs.org">&lt;aj@xemacs.org&gt;</a>
<li>Andy Piper <a href="mailto:andy@xemacs.org">&lt;andy@xemacs.org&gt;</a>
<li>Ben Wing <a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a>
<li>Didier Verna <a href="mailto:didier@xemacs.org">&lt;didier@xemacs.org&gt;</a>
<li>Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>
<li>Jan Vroonhof <a href="mailto:jan@xemacs.org">&lt;jan@xemacs.org&gt;</a>
<li>Jareth Hein <a href="mailto:jareth@xemacs.org">&lt;jareth@xemacs.org&gt;</a>
<li>Jonathan Harris <a href="mailto:jonathan@xemacs.org">&lt;jonathan@xemacs.org&gt;</a>
<li>Kyle Jones <a href="mailto:kyle@xemacs.org">&lt;kyle@xemacs.org&gt;</a>
<li>Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
<li>Michael Sperber <a href="mailto:mike@xemacs.org">&lt;mike@xemacs.org&gt;</a>
<li>Olivier Galibert <a href="mailto:galibert@xemacs.org">&lt;galibert@xemacs.org&gt;</a>
<li>Steve Baur <a href="mailto:steve@xemacs.org">&lt;steve@xemacs.org&gt;</a>
<li>Vin Shelton <a href="mailto:acs@xemacs.org">&lt;acs@xemacs.org&gt;</a>
</ul>
<h1>Primary Positions</h1>
<p>Primary positions are important enough that they should not
allowed to remain unfilled for any length of time. Detailed
descriptions of primary positions appear below.
<table border="1">
<tr>
<th>Position</th>
<th>Primary</th>
<th>Secondary</th>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#beta"><b>Beta Release Maintainer</b></a>
</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#binary"><b>Binary-Kit Coordinator</b></a>
</td>
<td>
Jason Mastaler <a href="mailto:jason@xemacs.org">&lt;jason@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#stable"><b>Stable Release Maintainer</b></a>
</td>
<td>
Vin Shelton <a href="mailto:acs@xemacs.org">&lt;acs@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#meta"><b>Meta-Maintainer</b></a>
</td>
<td>
Ben Wing <a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#core"><b>Core Patch Tender</b></a>
</td>
<td>
&nbsp;
</td>
<td>
Jan Vroonhof <a href="mailto:vroonhof@xemacs.org">&lt;jan@xemacs.org&gt;</a>,
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>,
Andy Piper <a href="mailto:andy@xemacs.org">&lt;andy@xemacs.org&gt;</a>,
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#package"><b>Package Patch Tender</b></a>
</td>
<td>
Andreas Jaeger <a href="mailto:aj@xemacs.org">&lt;aj@xemacs.org&gt;</a>
</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#cvs"><b>CVS Manager</b></a>
</td>
<td>
Jareth Hein <a href="mailto:jareth@xemacs.org">&lt;jareth@xemacs.org&gt;</a>
</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#postmaster"><b>Postmaster</b></a>
</td>
<td>
Jason Mastaler <a href="mailto:jason@xemacs.org">&lt;jason@xemacs.org&gt;</a>
</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#web"><b>Webmaster</b></a>
</td>
<td>
Sandra Wambold <a href="mailto:wambod@xemacs.org">
&lt;wambold@xemacs.org&gt;</a>
</td>
<td>
Marcus Thiessel <a href="mailto:jason@xemacs.org">&lt;marcus@xemacs.org&gt;</a>, John S Jacobs Anderson <a href="mailto:jacobs@xemacs.org">&lt;jacobs@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#bug"><b>Bug Tracker</b></a>
</td>
<td>
Gunnar Evermann <a href="mailto:gunnar@xemacs.org">&lt;gunnar@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>
<a href="Develop/jobs.html#i18n"><b>I18N Liaison</b></a>
</td>
<td>
Stephen Turnbull <a href="mailto:stephen@xemacs.org">&lt;stephen@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
</table>
<h1>Documentation Positions:</h1>
<p>All of the documentation is listed here. Some positions are
listed without primaries. It would be really nice if there were
people actively maintaining each of these documentation areas, but
slippage here is not so catastrophic.
<table border="1">
<tr>
<th>Position</th>
<th>Primary</th>
<th>Secondary</th>
</tr>
<tr>
<td>Lisp Reference Manual</td>
<td>&nbsp;</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>,
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>XEmacs User Manual</td>
<td>&nbsp;</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>Internals Manual</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
<td>
Ben Wing <a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a>,
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>PROBLEMS</td>
<td>&nbsp;</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>,
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>FAQ</td>
<td>
Sandra Wambold <a href="mailto:wambold@xemacs.org">&lt;wambold@xemacs.org&gt;</a>
</td>
<td>
Christian Nybo,
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>NEWS</td>
<td>
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>
</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>README</td>
<td>
Ben Wing <a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a>
</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
</tr>
</table>
<h1>Coding Projects</h1>
<table border="1">
<tr>
<th>Position</th>
<th>Primary</th>
<th>Secondary</th>
</tr>
<tr>
<td>General design issues</td>
<td>
Ben Wing <a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a>
</td>
<td>
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>,
Kyle Jones <a href="mailto:kyle@xemacs.org">&lt;kyle@xemacs.org&gt;</a>,
Olivier Galibert <a href="mailto:galibert@xemacs.org">&lt;galibert@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>Coding Standards</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Portable Dumper</td>
<td>
Olivier Galibert <a href="mailto:galibert@xemacs.org">&lt;galibert@xemacs.org&gt;</a>
</td>
<td>
Kyle Jones <a href="mailto:kyle@xemacs.org">&lt;kyle@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>Minimal tagbits implementation</td>
<td>
Kyle Jones <a href="mailto:kyle@xemacs.org">&lt;kyle@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Windows support</td>
<td>
Andy Piper <a href="mailto:andy@xemacs.org">&lt;andy@xemacs.org&gt;</a>,
Jonathan Harris <a href="mailto:jonathan@xemacs.org">&lt;jonathan@xemacs.org&gt;</a>
</td>
<td>
Adrian Aichner <a href="mailto:adrian@xemacs.org">&lt;adrian@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>Cygwin support</td>
<td>
Andy Piper <a href="mailto:andy@xemacs.org">&lt;andy@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Configure support</td>
<td>
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>
</td>
<td>
Didier Verna <a href="mailto:didier@xemacs.org">&lt;didier@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>Mule</td>
<td>
Ben Wing <a href="mailto:ben@xemacs.org">&lt;ben@xemacs.org&gt;</a>,
Martin Buchholz <a href="mailto:martin@xemacs.org">&lt;martin@xemacs.org&gt;</a>,
Olivier Galibert <a href="mailto:galibert@xemacs.org">&lt;galibert@xemacs.org&gt;</a>,
Stephen Turnbull <a href="mailto:stephen@xemacs.org">&lt;stephen@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>GUI support</td>
<td>
Andy Piper <a href="mailto:andy@xemacs.org">&lt;andy@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>Redisplay</td>
<td>
Andy Piper <a href="mailto:andy@xemacs.org">&lt;andy@xemacs.org&gt;</a>
</td>
<td>
Jan Vroonhof <a href="mailto:jan@xemacs.org">&lt;jan@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>Customize</td>
<td>
Jan Vroonhof <a href="mailto:jan@xemacs.org">&lt;jan@xemacs.org&gt;</a>
</td>
<td>
Hrvoje Niksic <a href="mailto:hrvoje@xemacs.org">&lt;hrvoje@xemacs.org&gt;</a>,
Didier Verna <a href="mailto:didier@xemacs.org">&lt;didier@xemacs.org&gt;</a>
</td>
</tr>
<tr>
<td>GPM support</td>
<td>
William Perry <a href="mailto:wmperry@xemacs.org">&lt;wmperry@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>The package system</td>
<td>
Steve Baur <a href="mailto:steve@xemacs.org">&lt;steve@xemacs.org&gt;</a>,
Michael Sperber <a href="mailto:mike@xemacs.org">&lt;mike@xemacs.org&gt;</a>
</td>
<td>&nbsp;</td>
</tr>
</table>
<h1>Job Descriptions For Primary Positions</h1>
<dl>
<dt><a name="beta"><b>Beta Release Maintainer</b></a>
<dd>The beta release maintainer is the primary maintainer for
XEmacs, and serves as the de-facto spokesman. His
responsibilities are (a) to put out new beta releases on a
regular basis, i.e. at least every one to two weeks
(depending on activity), (b) to go out of his way to be
responsive to e-mail sent to him and communicative about
and interested in important issues in all major aspects of
XEmacs, and (c) to decide when it's time to do an external
release. At this point, he is responsible for initiating a
code freeze and assuming quasi-dictatorial power over the
development process, doing whatever it takes to ensure that
a relatively stable, bug-free release gets put out in a
timely fashion. If some important job is not getting done
during the critical pre-release period, it is ultimately
the duty of the beta release maintainer (in conjunction
with the meta-maintainer) to ensure that this gets done,
for example, by finding somebody else who is willing to
take over this position, or (last resort) doing the job
himself. During periods when an external release is not
happening, the beta release maintainer goes back to being a
relatively low-key position, responsible primarily just for
putting out regular beta releases. It is imperative,
however, that the beta release maintainer continue to be as
responsive as possible to e-mail sent to him, because he is
the de-facto spokesman and is looked up to as the one
providing overall guidance for the project. If he fails to
respond to email, he will create the impression that the
entire project is in disarray.
<dt><a name="beta"><b>Binary-Kit Coordinator</b></a>
<dd>The binary-kit coordinator is responsible for organizing
the preparation, release, and distribution of pre-compiled
XEmacs software based on the stable branch.
<dt><a name="stable"><b>Stable Release Maintainer</b></a>
<dd>The stable release maintainer is responsible for putting
out `stable' releases of the code. These are generally
small updates to previous external releases. Once a major
external release happens, the development tree is forked,
with one branch becoming the stable branch, the other the
development branch. It is from this stable branch that
stable updates happen and it is the stable release
maintainer's responsibility to oversee this branch, decide
which patches belong in this branch, and do whatever else
is necessary to put out a stable update.
<dt><a name="meta"><b>Meta-Maintainer</b></a>
<dd>The meta-maintainer is responsible for defining and
managing the separation of XEmacs duties into spheres of
responsibility or "jobs". He maintains the list of jobs,
which lists the jobs, their descriptions, and the current
primary and secondary jobholder(s) for each of these
jobs. (Generally, the primary actually does the work of the
job, but if the primary becomes derelict in his duties, for
example by simply disappearing and becoming unresponsive to
email contact, the secondary steps in as the "acting
jobholder", until the primary returns (along with
assurances that he will not just disappear again) or
another primary is found.) The meta-maintainer is also
responsible, along with the beta release maintainer, for
filling empty positions and for noticing when a job is not
getting done. During pre-release cycles, the beta release
maintainer may take the most active role in filling
positions; during other periods, the meta-maintainer
primarily assumes these duties.
<dt><a name="core"><b>Core Patch Tender</b></a>
<dd>The core patch tender's responsibility is to make sure that
no patch to the core of XEmacs falls through the cracks.
Every core patch posted to XEmacs either needs to be
approved and then applied, or vetoed with a suggestion for
how to modify the patch so that it is acceptable. The core
patch tender is responsible for making sure that this
happens. If a patch is posted and is neither approved nor
vetoed within a two-week period, the core patch tender
needs to step up and make inquiries to determine what
should be done with the patch. If a patch is posted and
then vetoed with suggestions for improvements, but no
improved patch is submitted within a week or so, the core
patch tender needs to make inquiries to the patch submitter
to see if he can finish up getting the patch up to snuff,
and if not, the reviewers need to be contacted again.
<dt><a name="package"><b>Package Patch Tender</b></a>
<dd>The package patch tender's job is analogous to the core
patch tender's, except that it applies to the Lisp packages
that are, in some sense, external to XEmacs itself. His
job may be complicated by the fact that packages may have
active maintainers who may not be directly involved in
XEmacs development. In that case, he may need to track
down the active maintainer and try to get him to accept the
patch. The package patch tender also needs to create and
maintain a list of all the packages that are part of the
full XEmacs development tree. For each package, this list
should specify the package's home page (if any), the
maintainer and his contact address, any mailing lists
devoted to the package, the number of the latest release
and where to get it, the corresponding XEmacs package
release number, and (if the information is available) a
subjective judgment as to how well the package is currently
being maintained, from 0 (package is obsolete, no one has
maintained it in years) to 5 (package contains an active,
well-organized development effort with regular releases,
mailing lists, a web site, etc.).
<dt><a name="cvs"><b>CVS Manager</b></a>
<dd>The CVS manager is responsible for all CVS issues related
to XEmacs.This includes, for example, the CVS trees for the
core and thepackages, and the CVS web interface. This
includes the important but thankless task of doing backups.
<dt><a name="postmaster"><b>Postmaster</b></a>
<dd>The mailing list manager is responsible for maintaining the
XEmacs mailing lists.
<dt><a name="web"><b>Webmaster</b></a>
<dd>The webmaster is responsible for maintaining the
www.xemacs.org web site.
<dt><a name="bug"><b>Bug Tracker</b></a>
<dd>The bug tracker is responsible for keeping track of all the
bugs that have been posted anywhere, either to xemacs-beta,
comp.emacs.xemacs, or similar sources. Properly speaking,
they need to be kept in a database, assigned priorities,
severities and owners, and managed in the standard way that
bugs are managed. Unfortunately, we don't currently have
such an infrastructure, so it's the current responsibility
of the bug tracker to keep track of the bugs in any way
possible (e.g. just a simple list), with the number one
cardinal rule being: <b>NO BUG MAY FALL THROUGH THE
CRACKS</b>. Every bug that gets reported through any
standard means needs to end up on the list, along with as
much information as possible from the bug report: The name
of the person reporting the bug, the version number of
XEmacs being run, the circumstances and behavior of the
bug, etc. etc. etc. The secondary responsibility of the
bug tracker is to investigate a workable bug-tracking
system for XEmacs. I know that the Samba project has such
a system in place, so we should just be able to use theirs,
for example.
<dt><a name="i18n"><b>I18N liaison</b></a>
<dd>The I18N Liaison is responsible for synchronizing
maintenance and development of language environments with
Mule development. "Language environment" includes features
like input methods, standardization issues, language
defaults and user setup, etc.
Language skills, for both feature specification and
coordinating communication, are a plus. (With the current
user and developer, Japanese is most useful, but developers
with skill in R2L BIDI languages, eg Hebrew, are eagerly
sought. Any language character sets other than ISO-8859-1
is very helpful).
</dl>
This diff is collapsed.