Source

xemacsweb / Develop / jobs.content

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542

%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>