Minimal version of Mail::Mailer

[Vlad Dascalu]

Hey Shane, thanks for the reply and insightful comments!

>A sandwich-making machine would be hella cool, and it's certainly worth
>tinkering with because it would make our lives easier if we got it working.
>Until that day, however, we still have to deal with the problems of hungry
>individuals.
>
I prefer my "forrest and the trees" example. Suppose that you could spend
$1 and fix a tree, or you could spend $10 in research for saving the whole
forrest.

The catch here is to figure out what is better to be done: spend those $10
on 10 trees, or research on saving the forrest.

(consider $1 as one month of the developer's time and so on)

There are different solutions for different scenarios. Not all of them
require a one-fits-all solution. I've noticed for example that you tend to
take the $1 - fix a tree solution all the time, while Jake, for example,
takes the $10 thing.

Having the "big picture" means having the knowledge and insight to make
the right choice. Just like it's the right choice to fix a severity field
related bug (the $1 tree fix) instead of waiting for custom fields to
abstract it out, it might be the right choice to do a FAQ overall instead
(the $10 forrest research thing) instead of fixing it with small patches.

If you get to know yourself/the project, and if you have the ability to
estimate correctly the difficulty of the problem, you will end up with the
right choice and get to the results in optimum time (with the least sum of
money spent). Especially when you can't/don't have the resources/time to
fix both the trees and the forrest, it's important to prioritize, assert
the difficulty and the complexity of the forrest and see if we're going
for the trees, for the forrest or for both.

>Hmm... leader of the project says it is, Vlad says it isn't. I wonder who
>I should be listening to?
>

Depends upon what are your purposes related to this project's development.
If your interests are related to the Bugzilla code development, then you
should see the project leader as a tool that takes hard-to-make collective
decisions, like what to go in or not, or what User Interface should we
have, etc. Those are (and probably some others are as well) areas where
the "benevolent dictator" makes the decisions after consulting with the
community, because it's more effective that way. That opinion should be
respected, unless you are ready to fork the tree and take your own path.

However, to respect doesn't mean to listen only what you respect. You can
respect the decision made by the leader/community, and still believe
another thing. In order to do that, you have to think, listen to both
sides, both arguments, and consider them on their own. No matter if they
are coming from the project leader or from a non-canconfirm b.m.o. poster.
At http://open-site.org, we specifically removed, for this reason only,
the editor titles that used to appear below their name, in the forum.

So you should respect the decisions of the community where you choose to
belong, but you should listen to everybody with an equal voice and listen
to yourself and your judgement for reviewing the facts.

>By all means, plan for the future. Long-term goals are needed... but so are
>short term solutions.  You wanna talk about creating a sandwich-making
>machine? By all means, do so... but don't criticize someone who is trying to
>address the issues that exist *at this moment* by actually getting his hands
>dirty and making a sandwich.
>

Why not? If a community could decide, via rationale means, that it's
better to aim for the forrest instead of the trees, don't you think that
someone should voice this opinion? I think it's productive to give
feedback (criticize is kind of harsh) when it has the potential to help.

Vlad.