<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/2/2016 4:38 PM, R. Kent James
wrote:<br>
</div>
<blockquote
cite="mid:c1eeb643-e57e-9fc1-11bd-df5fc2d52ee5@caspia.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<p>I've had some discussions with James Quilty about major student
engineering projects involving Thunderbird. Here is his
proposal, and he is asking for specific suggestions of
appropriate projects.</p>
</blockquote>
<br>
From what I've heard, the quality of undergraduate students can be
highly variable, although I will admit that this in the context of
research projects which tend to require highly specialized knowledge
compared to "average" OSS development. I'm also notoriously bad at
estimating how much time it would take to implement or prototype
something, so it's hard for me to gauge the appropriate scope,
especially since this seems to be on a scale which is somewhat
larger than a typical GSoC project. On the other hand, given that
this is a software engineering course project, I would assume that
ensuring that there is high coverage of corner cases and tests has
higher priority than you tend to see in a GSoC project.<br>
<br>
Nevertheless, there immediately comes to mind a few projects that
might be feasible:<br>
1. The ensemble project, aka, the new address book. This is
self-explanatory.<br>
2. Rebuilding the S/MIME UI (and potentially integrating Enigmail
into that UI). The current UI and UX, particularly when it comes to
managing the known certificates, is basically structured around the
assumption of SSL certificates, which S/MIME certificates are quite
emphatically not, and hence it's particularly nasty to use for
novice users. The biggest challenge here is finding a capable mentor
for the project, since I suspect none of us are particularly
cognizant of NSS internals with regards to certificate validation.<br>
3. Fixing compose UI. The smaller segment that comes to mind is the
addressing widget, which is thoroughly in need of a complete
rebuild. The larger segment would be tackling issues with regards to
the editor, as well as rebuilding things to use HTML instead of XUL.
Ultimately, though, I do fear that the backend is unsuitable for the
changes that need to be made, and I don't think it would be terribly
feasible for the students to have to deal with ongoing changes
there, as much as I would like to see this sort of project go
forward.<br>
<br>
There's a few other projects I can think up, but they run afoul of
the "mission-critical" or the "mostly bag of bugfixes" that we are
suggested to avoid.<br>
<pre class="moz-signature" cols="72">--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist</pre>
</body>
</html>