[EMAIL PROTECTED] writes:

> it's good to hear from someone who isn't pretending to be a/speak for
> the developers.

Kestas, several core PF developers have responded to your original
message and various follow-ups, essentially trying to elicit some sort
of fact-based reasoning why this feature should be developed by them.

Your response to them has been essentially "Some other product has this"
mixed in with some repetions of "I want this", combined with a liberal
dose of name-calling.  Neither of these approaches are terribly useful
as tools of persuasion.

Discussions of this general mold seem to pop up with alarming frequency,
so I will outline some of the smarter ways to get developers' or more
experienced users' attention -

* "Some other product has this, why can't PF do this" 

  Well, in most cases it is likely that PF can indeed do what you want,
  but possibly in a slightly different way than what you would do with
  the other product.  If you are able to explain to other list readers
  what it is you want to achieve, some helpful user is likely to point
  you in the right direction.

  Offering explanations of what you want to achieve is always a lot more
  useful than quoting a chunk of some other product's configuration file
  claiming that PF is deficient if its users can't parse product foo's
  configuration file.


* "I want this! I'm sure PF does not have this"

  It is possible that you have indeed found a useful feature which could
  usefully be implemented.  If you have identified a missing feature
  which you feel is essential to your network, then clearly something
  needs to be done.  

  Making the case for a new feature to be implemented takes a bit of
  work (offering up some code for review usually helps), most important
  is making a well reasoned case that this is a) actually a useful
  feature and b) the feature belongs in the base system.

  It is quite possible that your project satisfies condition a, but not
  condition b, which means that it is better off as a separate program
  to be maintained outside the base system.  Examples of "a, but not b"
  features which became widely used programs maintained outside the base
  system are pftop and expiretable.


* "You're a bunch of mindless moron zealots! I want to talk to the real
  developers!"

  The likelihood that the stranger on the PF mailing list telling you
  that your favorite missing feature is not worth implementing is indeed
  a real developer with commit access to the source tree is far from
  negligible.  

  If your explanation of the obvious goodness of your wished-for feature
  does not convince, you should consider the possibility that a) your
  idea isn't actually that obviously good or b) you need to work a bit
  more on that explanation.  Abuse and name-calling never helps your
  case, ever.
 
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
"First, we kill all the spammers" The Usenet Bard, "Twice-forwarded tales"
20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds.

Reply via email to