There's no difference between an XEmacs user and an XEmacs developer
except how they label themselves. If you want to be an XEmacs
developer, just do it:
0. There's some information about development at
http://www.xemacs.org/Develop/. Read it.
1. Subscribe to xemacs-beta, xemacs-design, and maybe xemacs-winnt,
or read them via gmane, or at the archives
http://list-archive.xemacs.org/.
2. Fix bugs or implement features. New features often are best
discussed on xemacs-design before implementation. Submit patches to
xemacs-patches. Once you're known to the core people, you can
request, or be offered, commit privileges to the CVS repository. This
is basically a convenience; commits must be approved by a Review Board
member or a package maintainer.
3. If you're looking for a more formal but limited responsibility,
consider studying one of the Lisp packages labelled "maintained by the
XEmacs Dev Team," and taking over as its maintainer. This also
carries the privilege of approving patches (including your own) to
"your" package.
4. Most of the other formal responsibilities (see
http://www.xemacs.org/Develop/jobs.html) are performed by members of
the XEmacs Review Borad. The XEmacs Review Board is basically a
self-perpetuating cabal. Membership is by invitation. The criterion
for membership is basically a demonstrated willingness to review
patches, or help with the managerial scutwork of the project (mailing
list management, package maintenance, etc). If you think you're ready
for membership, you can solicit an invitation. Of course, if that
demonstrates bad judgment it can count against you for a while, but
there's no reason not to do so in principle. Writing documentation,
especially for other people's features, is definitely a plus.
--
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.