spf-discuss
[Top] [All Lists]

Campaign: If elected I will ...

2004-11-24 19:56:28
As I see it, the SPF community is currently lacking in three things:
--------------------------------------------------------------------

1.  A public face.
2.  Internal cohesion and awareness of group consensus.
3.  The ability to make a group statement.

(Other areas and methods of messaging accountability are also lacking in
these three things, though to a somewhat lesser extent.)

The *current* result of these deficiencies is that:
---------------------------------------------------

  o  We have slightly incompatible proposed standards,
  o  We have slightly incompatible libraries,
  o  Practically everyone on the spf-discuss list has their own
     set of slightly-incompatible suggestions for best-practices.

So the *end-result* is that:
----------------------------

  o  Even though these incompatibilities should not affect most
     potential SPF deployments for technical reasons, they can affect
     potential SPF deployment for marketing-type reasons--It looks
     daunting to people who have not been SPF for a long time to see
     such seeming disagreement, and so it can *look* like a reason to
     delay deployment altogether.

As long as we have the deficiencies above, those deficiencies will
result in "minor" problems such as the above.

As I see it, the primary purpose for a council is to address those
deficiencies.  (Both for SPF, and for messaging accountability in
general, though I am open to arguments for/against on the latter.)

This means that with a council:
-------------------------------

1.  We would have a public face:

    Once we have an actual community viewpoint that the council
    can claim to represent, at the very least those who discuss
    or complain about SPF can direct their comments to a real
    set of positions.

    We can at least avoid waisting time responding to imagined
    goals.  (Folks who haven't kept up with SPF often have incorrect
    ideas on things.)

2.  We would have greater internal cohesion:

    It would be nice to avoid waisting time rehashing old topics
    with no new information.

    It would be more useful if, even internally, we had a clear
    idea of group consensus on decisions.  Currently it's as if
    that information has a half-life of about a month or two.

    Everyone wants a real spf1 spec hammered out, but we keep getting
    side-tracked on lesser issues that have already been resolved
    multiple times.

3.  We would have the ability to make a group statement:

    o  It would be useful to say that "The SPF community believes/
       claims XXX".

    o  Before submitting a document through IETF, it would be useful
       to publicly claim it as being supported by the SPF community.

       *** This would mean we could have an actual official-type
       *** non-ietf standard before going through the ietf and
       *** requiring many more months.  We *need* at least some
       *** sort of official standard to point to, even before
       *** going through full ietf procedures.

Successfully addressing these issues will mean that we can finally get a
final spf1 spec hammered out internally, officially approved by the
council, and started along the ietf procedures.

Everyone is eager to have an spf1 spec done, but we can't officially
claim the group supports any spf1 spec until there's a way to officially
make such a group statement.

So my goals would be to:
------------------------

1.  Make sure the existence of the council does in fact solve 1,2,3 
    above.

2.  Push for and work for an spf1 spec to be at the very least
    internally finalized, *quickly*.

3.  Be open to officially addressing wider problems, (unified,
    scoping), after an internal spf standard is complete.

4.  Bear the brunt of public complaints, lessening the load of
    general complaints that the real developers might otherwise
    bear.  The council puts a public face on the community, and
    should address public criticism.

Mechanics I will be in favor of:
--------------------------------

1.  Ranked polling to gage consensus on technical or nontechnical
    items of potential contention when there is no obviously-clear
    consensus or when it would not be appropriate for the council
    to make a decision on it's own.

2.  The ability for a group of members to force a poll on individual
    members or member decisions, so that if the council were to be at
    serious odds with the members, that that fact could not be hidden.  

    (In other words, I want the council to be able to work without
    the need to constantly annoy members with polls on every little
    thing, but the underlying threat that if the council turns out
    to be working against member interests, that there's the serious
    potential that they can lose their legitimacy quickly.)

Principles I will endeavor to uphold:
-------------------------------------

1.  Open Processes.

    I realize that I may end up in situations where I may be asked
    to hold secrets for a time.  There are circumstances where I
    would understand such requests and could agree with them.

    For instance, I would consider it appropriate to be privy
    to plans an ISP has to announce SPF support on a certain day,
    since that could be both to the ISP's advantage and the SPF
    community's advantage, and it has no elements of dishonesty
    toward the SPF community.

    However, agreements of the type of "we will give up this,
    if you give up this", are generally unacceptable if I am
    required to keep the idea secret past a few days.  (They're
    also unacceptable because even the concept of secretly changing
    a group's represented stance on something doesn't really
    make sense.)

    (Note of conflict of interest:  As part of another project,
    I am wanting to push the notion of a patent cross-licensing
    agreement.  This *does* puts me in a position of keeping
    internal company plans secret, since I will want to ask
    companies their viewpoint on signing up to such an agreement,
    and companies have not so far been keen on having their interests
    publicized in advance.  However, though this can represent
    with being on the SPF council in theory, in practice I don't think
    it would really represent anything the membership would find
    objectionable, as it would tend to be in the interest of spf-related
    organizations to publish their interest in such a thing instead
    of having me keep things quiet.  I've tried to figure out how
    this could represent an actual conflict-of-interest in practice,
    and haven't come up with anything.)

2.  Iterim elections-of-confidence/no-confidence.

    Once the council structure and other preliminary work is finished,
    I want to hold iterim elections to allow members to approve or
    disapprove of the current setup.

    I don't see a need for immediate elections 2-3 weeks after council
    formation, but I would want that to be put to a vote.

3.  Personal recognition of no-confidence.

    If I am a hindrance to the council's operations, I will try to
    swallow my pride and resign, so that someone more competent can
    take my place.  I will take such suggestions seriously.

The virtue of laziness:
-----------------------

This part will sound rather odd.

The spf community is full of stunningly competent people.

It would be silly for the council to try to "take over" in-depth
technical work, and I'm not competent enough to do so even if I were so
misguided as to try.

However, it would be useful for the council to do the almost make-work
job of collating things like "these are things that have been decided",
and "the only remaining decisions in the spf spec are X, Y, and Z--let's
discuss them now".

And if we change the name to the "Authenticated Messaging Standards
Group", after finishing our internal standard, we could officially call
it a document name of AMSG #1, so that other folks would have an
official standard to look at, before it goes through ietf and is further
polished.

It would also be useful for the council to make official responses to
public discussion of SPF.

After initial setup, I see my work as accepting blame, collating
internal positions, editing group position papers, and preventing
roadblocks that keep the work of the actual developers from being taken
seriously and used by PHB types:

o  The actual work will still be done by the same developers as before.

   I want them to have whatever remaining structure they might still
   need--and there's not much that they'll need I expect.

o  PHB types need to see that we have a standard we are all in favor of.

   Proclaiming a standard we end up with as our official standard,
   (only not yet "polished" via IETF), should be enough for most
   of those who have not yet been convinced.

o  Internal SPF folks need to keep track of our internal positions.

   That's also pretty straightforward really.

o  The outside world needs to know what we represent, what we think,
   and who to contact for any particular type of question.  That's
   also pretty straightforward.

In other words, I am not running to edit the spf1 spec myself.  Thoguh I
have suggestions, other people are *far* more competent at that.  I am
running to pull roadblocks out from in front of them, which admittedly
is far less work.  (I am trying to start a business, and I will *not* be
able to devote that extent of time to the council anyway.  However, I
can work to do the above listed things, which involve less time, and are
the things that I currently see as the spf community's blocking points. 
However, if you do believe that even the above requires more serious
time commitments than someone starting a business would be able to
consistently give, that would be a very valid reason to vote for someone
else.)

Conclusion:
-----------

I once worked at a cubicle-farm type place where..if you looked at the
office, you couldn't really see all the technical stuff that everyone
was doing at their workstations.  It just didn't *look* impressive to
PHB types.  (It was way-cool looking to technical types though.)

So some management-types spent some serious money to redecorate
everything so that it would *look* official and impressive, and suddenly
they could get more customer accounts as customers would see the more
impressive decor as more legitimate.  It sounds silly, but it worked.

Most of the SPF community's problems are similar--folks don't see us has
having a solid position--and as it happens, merely documenting our
positions will help us internally anyway.

So making an official council (with whatever name is chosen), will give
the group more credibility, will help things from the outside, won't
detract from the technical work, will likely even speed along the
technical work, and will let us/me push for a *quickly* finished
internal spf1 spec--and it will let us immediately give official weight
to the spec.

I am not competent to do most of the technical work, but fortunately,
there are many people in the SPF community who are.  But if you want me
to help hold up some scaffolding so that the external community deploys
spf faster, and so the internal community works better together--I can
do that for you.

-- 
Mark Shewmaker
mark(_at_)primefactor(_dot_)com


<Prev in Thread] Current Thread [Next in Thread>