[Enigmail] The RFE process

[Robert J. Hansen]

http://mozilla-enigmail.org/forum/viewtopic.php?t=395

The rest of my remarks are going to assume you've read that FAQ entry.

The process of requesting enhancements is usually called "filing an 
RFE", where RFE stands for "Request For Enhancements".  We get a ton 
more RFEs than actually get implemented.  I thought maybe some 
discussion of the RFE process would be appropriate.

All successful RFEs go through a few distinct stages.  If you want your 
RFE to be successful, craft it in a way that works with the process 
instead of against it.

	1.  Triage
	2.  Ignoring
	3.  Evaluation
	4.  Selection
	5.  Implementation


1.  TRIAGE

"Triage" is a medical word which means "separate the ones in no risk of 
dying from the ones who are likely to die from the ones who are going to 
die."  The patients in the first and last categories get ignored, so 
that all medical efforts can be concentrated where they may possibly do 
some good.

RFEs get triaged, too.  They get separated into "accept", "maybe" and 
"reject".  The triage depends on how clearly you've articulated the 
problem, how clearly you've articulated the desired enhancement, and how 
many users this will impact.  An incoherent description and articulation 
will get kicked into the "reject" pile.  So will a coherent description 
and articulation of a problem that affects only one or two users.

An accept means your RFE is ready to be ignored (see step 2).

A "maybe" means your RFE could potentially be ready to be ignored, but 
right now it's not just there.

A "reject" means your RFE is unlikely to proceed any further in the process.

If your RFE gets rejected, don't take it personally and don't complain 
about how stupid the triage process is.  We're not casting any judgment 
on you--we're only casting judgment on your idea.

You are not your idea.



2.  IGNORING

Very few RFEs need to be implemented immediately.  The Enigmail team can 
certainly act on RFEs immediately, but as a general rule, we don't.  The 
reason why is we want time to reflect on it, to think about how this RFE 
will change things for other users, and more.  And sometimes the team is 
just busy with other things, including real lives--some of us are 
married, some of us have life partners, some of us have Ph.D. 
comprehensive exams a week from tomorrow.

 From a user perspective, it may seem like we've accepted the RFE but 
we're just sitting on it.  Please trust me: we're not.  We're doing a 
long-accepted practice in software engineering of letting ideas 
percolate and settle for a while before going further with it.  The 
"ignoring" stage may last for anywhere between a few days to a few 
weeks, depending on the urgency of your RFE, the time the team has to 
commit to the project, and various other factors.



3.  EVALUATION

Now that the team has accepted the RFE and spent some time studying it, 
we now need to decide where in the big To-Do list this RFE should be placed.

RFEs are not a queue.  We do not do them in order.  In fact, we usually 
don't even bother with a formal To-Do list.  Most RFEs are of 
sufficiently low priority that we don't need to arrange them in any 
specific order.  It's only when an RFE becomes either urgent or fun that 
the team begins to talk about "yeah, we should do that one next".



4.  SELECTION

Finally, the coding staff (which is to say Patrick) picks an RFE to work 
on.  Patrick's decision is final and inarguable.  He's writing the code, 
so he gets to decide what he works on.  I have never seen anyone on the 
team tell Patrick he really should be working on something else.  I'm 
pretty sure all of us would find that incredibly rude.

If you want your RFE to get implemented in a hurry, it should be either 
urgently-needed or else a lot of fun to implement.



5.  IMPLEMENTATION

Your RFE is now in Patrick's capable hands.  It will be done when it's 
done.







... As an example of some RFEs, take a look at one I filed last August:

https://www.mozdev.org/bugs/show_bug.cgi?id=17490

It was first proposed on the devel mailing list.  It bounced around 
there for a while, getting feedback from other users, before I pitched 
it to Patrick as an RFE.  It got triaged as a "yes", and sat in the 
ignore list for a while.  It got evaluated as a low-priority item, and 
it will get selected and implemented once Patrick gets around to doing 
low-priority items that aren't very fun.  :)

It's been in the queue for eight months with no action taken yet. 
That's the nature of the beast.  Sometimes you have to wait for a while, 
especially for low-priority, non-fun fixes.

If you're really bothered about your RFE, I suggest grabbing the latest 
nightly source and writing a patch.  That can really jumpstart the 
process--we field tons of requests from tons of different users, but we 
hardly ever receive patches.