Re: Now and then

[Ask Bjoern Hansen]

On Wed, 11 Oct 2000, Adam Turoff wrote:

[..]
> titled - RFC ## (v#): Add XYZ into Perl.  That traffic is also easy
> to find in the archives.
> 
> That will probably be less of an issue with a strong lack of RFC
> activity during the implementation phase.  It very well could be
> that anyone doing serious work is going to subscribe to perl6-all,
> and the perl6-* lists exist for those who just want to listen.

Yes, I agree. And for those who are trying to do something the
implicit rough sorting in topics the different lists give are also
helpful. Or so it is for me.


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: Now and then

[Bryan C . Warnock]

On Wed, 11 Oct 2000, Nathan Torkington wrote:
> Then again, remember the hassles we had with the perl6-* lists?
> Nobody knew how to deal with topics that overlapped lists.  You had
> to know all the groups to decide which it was appropriate for.  Are
> these big enough hassles to suggest that perhaps the perl5-porters
> All In One list wasn't such a bad idea after all?

To a point.  Instead of top-down or bottom-up, you shoot for somewhere
in the middle, although probably closer to the bottom.  Start with the
lowest-level stuff that still has commonality with other group.  Hash
out the similarities, differences, and directions.  While the groups
and community build up from there, a group of people stick around to
fill in the pieces of their portion.  You certainly don't want to
isolate similar development, but there's no need to flood discussions
with specific patter, either.

I picture it much like the mega-conglomeration merger talks.  Two big
honchos sitting across the table from each other, hashing out the rough
direction of whatever end agreement they want to take, all the while
taking in advice from advisors, shareholders, etc.

Once they've roughed out an outline of what the agreement *should be*,
they dismiss the little people to flush out the details - cross the
i's, dot the t's, that sort of thing.

This would probably work better for more open development, too, as it
would give more junior folks a chance to contribute what Damian calls
"trivial implementations."  You're going to find far fewer people who
are able (or willing) to code some perl functionality from end to end
than if you were to have the few able bodies able to hash out a
thorough framework, and have the nugs contribute bits and pieces within
the framework

Take, for instance, the whole async i/o issue - I've not Clue One (I
think) about how to go about writing my own i/o lib, async or
otherwise, even though it's an area I'd like to contribute to.  Given
the current end-to-end scheme, I'd never get to do anything, and Uri
and Company are going to be coding in the dregs  There's no reason
that they couldn't get the base down, work more on flushing out its
functionality, and turn over some of the more trivial stuff to some of
us trying to be a little more active.

Hmmm, I seem to have digressed from the original point

  --  Bryan C. Warnock
([EMAIL PROTECTED])

RE: Now and then

[Nathan Torkington]

David Grove writes:
> That's fine, you've been patient, considerate, understanding, and extremely 
> helpful. You deserve a nap... or a beer, your choice.

Having done what they said couldn't be done (making David Grove happy
with Perl) I'm off for a Guinness!

Nat
(and then a nap :-)

RE: Now and then

[David Grove]

On Wednesday, October 11, 2000 3:45 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:

[snip[

> documentation, etc.  The teams will obviously work together at time.
> Each team has three roles identified: the person who checks in
> patches, the person who represents user interest in that area, and the
> person who QAs that area.  There may be others, members of the public,
> but these three are the ones who must be satisfied with a release
> before it can go out.  There is no team leader, merely the union of
> those three people.  The release manager is there to help each team
> work with its team members, and to help teams work together.

> The system is self-balancing.  The release manager cannot override a
> team that will not approve a release.  If teams want to kick out the
> release manager, they can get together and do so.  The release manager
> should be involved in intra-team disputes to ensure that booting a
> team member out is an action of last resort and not merely a way to
> force a release through over valid objections.

[snip]

Everything 100% A-OK, clear, agreed, and sounds wunnerful.

> > Anyway, it's definitely moving in a good direction, and shows
> > potential to solve a majority of problems. Yes, this is a good
> > direction.
>
> What else is there to say?  I want to get this topic dealt with so

Naw, I just meant that it sounds good in theory. As you've pointed out, it just 
needs to be seen in actual practice. Also, IIRC, it has to be "approved".

> I tend to lose patience with any thread that goes on for longer than
> three days, so we're reaching the end of my ability to focus here :-)

That's fine, you've been patient, considerate, understanding, and extremely 
helpful. You deserve a nap... or a beer, your choice.

RE: Now and then

[Nathan Torkington]

David Grove writes:
> If I understand correctly, large teams would have a small team of
> "control" (bad word, but I don't know how else to put it) with a
> team manager for that team, and small teams (like the ones with two
> or three members, that have been pointed out) would be their own
> "control" team, and unanymity of teams would be required for
> release, is that a good summation?

I think so, although I'd have written it better.

The ongoing maintenance of Perl will involve work done by teams of
people.  Each team focusses on an area: compiler, regex,
documentation, etc.  The teams will obviously work together at time.
Each team has three roles identified: the person who checks in
patches, the person who represents user interest in that area, and the
person who QAs that area.  There may be others, members of the public,
but these three are the ones who must be satisfied with a release
before it can go out.  There is no team leader, merely the union of
those three people.  The release manager is there to help each team
work with its team members, and to help teams work together.

The system is self-balancing.  The release manager cannot override a
team that will not approve a release.  If teams want to kick out the
release manager, they can get together and do so.  The release manager
should be involved in intra-team disputes to ensure that booting a
team member out is an action of last resort and not merely a way to
force a release through over valid objections.

> Anyway, it's definitely moving in a good direction, and shows
> potential to solve a majority of problems. Yes, this is a good
> direction.

What else is there to say?  I want to get this topic dealt with so
we can return to the more pressing tasks:
 - how will we evolve and record design decisions (the RFC or
   RFC-replacement)
 - by which people and in what groups will design take place?

I tend to lose patience with any thread that goes on for longer than
three days, so we're reaching the end of my ability to focus here :-)

Nat

RE: Now and then

[David Grove]

On Wednesday, October 11, 2000 2:34 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:
> David Grove writes:
> > I'm not sure that unanymity wouldn't be going overboard for Perl,
>
> Except that it's not unanimity of individuals, who are cantankerous
> and troublesome, but unanimity of teams.  Each team has the moderating
> influences of three people to try to reach consensus.  The release
> manager might work with a team that can't agree to help them reach a
> decision, but nobody would be imposing will from above.
>
> > but that would be a decision internal to the QA group, correct?
>
> The QA group ain't special.  It has a role to play, but so do the code
> maintainers and the user liaison folks.
>
> > Have I tangented with this, or are we still making sense to each other?
>
> You seem still to be making sense.  Are we agreed that we have a good
> ongoing model to try when we get to that stage?
>
> Nat

I agree that it's moving it a positive direction, yes. Especially when no two 
or more members from a given - company is not a right word here, Nat... - 
"point of view" (ActiveState, Solaris, Digital Unix - no, er, "qlique"(?)) 
would be on a team. How to define that would be difficult, but the effect would 
have to be better than before. That would almost have to be a judgement call by 
the team manager. If I understand correctly, large teams would have a small 
team of "control" (bad word, but I don't know how else to put it) with a team 
manager for that team, and small teams (like the ones with two or three 
members, that have been pointed out) would be their own "control" team, and 
unanymity of teams would be required for release, is that a good summation? 
Anyway, it's definitely moving in a good direction, and shows potential to 
solve a majority of problems. Yes, this is a good direction.

RE: Now and then

[Nathan Torkington]

David Grove writes:
> I'm not sure that unanymity wouldn't be going overboard for Perl,

Except that it's not unanimity of individuals, who are cantankerous
and troublesome, but unanimity of teams.  Each team has the moderating
influences of three people to try to reach consensus.  The release
manager might work with a team that can't agree to help them reach a
decision, but nobody would be imposing will from above.

> but that would be a decision internal to the QA group, correct?

The QA group ain't special.  It has a role to play, but so do the code
maintainers and the user liaison folks.

> Have I tangented with this, or are we still making sense to each other?

You seem still to be making sense.  Are we agreed that we have a good
ongoing model to try when we get to that stage?

Nat

RE: Now and then

[David Grove]

On Wednesday, October 11, 2000 11:02 AM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:
> David Grove writes:
> > I'm wondering how different this is from the current setup.
>
> Currently there's the pumpking and the pumpking decides when to
> release a new version of Perl.  This exposes the pumpking to all sorts
> of allegations, and potentially exposes Perl to being bought out.
>
> When no single person can force a release through, both problems go
> away.  It's distributing the current pumpking's responsibility
> (integrating patches, quality control, communication and deadlines)
> to more people.  This has the added benefit of hopefully avoiding
> pumpking burnout.
>
> > Points of clarification, however. QA team determines definite
> > preparedness for release?
>
> It's a joint decision.  If QA likes it, but the code person doesn't,
> they have to sort that out between themselves before the release can
> happen.  If the user liaison says "we've been promising this for the
> last three releases, we can't make another release without it" then
> the others have to listen.
>
> But nothing can be released without QA's approval.
>
> Nat

Yes, that satisfies my concerns by providing "checks and balances" to the 
system.

Bjarne Stroustroup in "The Design and Implementation of C++" talks about ANSI 
and the C++ committees, and how he's always tried to get real strings into the 
language as a basic data type, but every time he brings up the subject either 
Dennis Ritchie or a chinese lady whose name escapes me raises her hand and with 
that it's all over. The setup there is that it has to be unanymous. The need 
for unanymity slows down the process, but provides for a completely stable C++ 
implementation. I'm not sure that unanymity wouldn't be going overboard for 
Perl, but that would be a decision internal to the QA group, correct? Or 
something determined by Larry? There's definite pros and cons each way. 
Basically, the cons are that some things would never end up in the perl core, 
and the pros are that certain things would never end up in the perl core, like 
temporary and experimental "fixes" that don't work implemented mainly for a 
marketing stunt and that have the byproduct of disabling major features of the 
language...

Have I tangented with this, or are we still making sense to each other?

Re: Now and then

[Nathan Wiger]

Nathan Torkington wrote:

> The immediate question facing us is how to structure software design.
> This is different from the ongoing maintenance of Perl.

> The architecture will be partially decided by Larry, and seems best
> done by a few experienced with such things.  Detailed design seems
> appropriate for groups of 5-10 people in each area.  In both cases,
> public viewing of the proceedings is mandatory (you can read their
> messages and see their thoughts and comment in private).

> I'm thinking about a team structure for ongoing maintenance.  Each
> area (docs, stdlib, interpreter, compiler) has its own team.  A team
> is only a few people: the person responsible for submitting patches,
> someone responsible for keeping on top of user demands, and someone
> from QA.

[rest of excellent ideas cropped]

Nice. I like it alot. The one thing I don't like is "comment in
private", but see below.

My main concern at this point is *how* these teams are assembled. Here's
my shot at a relaxed yet fair process, let me know what you think. The
specification seems long (just so I can be clear), but it's actually
pretty simple.

1. With either development or maintenance, at some point it's generally
decided that something should warrant a team. For example, perhaps Async
I/O, or Unicode, or whatever. Somebody volunteers to be "team lead", but
not that they have any more authority, just that they guide stuff
similar to sublist chairs. The team lead should also be responsible for
making sure their team is properly in synch with other teams.

2. The team lead puts together a short synopsis of what's required for
the team, what the private sublist is going to be, and how many people
are needed. This synopsis is posted on dev.perl.org.

3. Prospective members then email the team lead, asking to be on the
team. The team lead is responsible for asking them "What are your
qualifications?" or "Why do you want to do this?" or whatever. Through
this process, the team lead selects their team and sends the list to Ask
(or whoever's in charge of sublists). Those members are added to the
sublist, and the team description on dev.perl.org is marked as "closed".

4. The team uses the private sublist to conduct their business. Others
can read the archives, and observe. To post concerns, anyone should
still be able to email the private sublist, on a moderated basis (like
perl6-announce). That is, emails to the private sublist from those not
on the list should have to be approved by the team lead. That way,
reasonable concerns can still be raised publicly (and archived
correctly), and useless/out-of-date ones can be denied or answered
privately. It also prevents people from posting to -internals or -meta
with "Those -internals-io people have it all wrong, blah blah blah".


So, for example, if -internals decided that an Async I/O group was
needed, and Uri volunteered to lead it, it might look something like
this:

 Teams
 -
   Name: Asynchronous I/O
   Lead: Uri Guttman <[EMAIL PROTECTED]>
   Sublist: [EMAIL PROTECTED]
   Needs: 5-10 people
   Members: (open)
   Mission:
  This team will be responsible for the design and implementation
   of fundamental asynchronous I/O for Perl 6. Those interested should
   be experienced with low-level I/O programming, such as UNIX device
   drivers or STREAMS. We will be designing I/O API's, prototyping,
   and finally writing production code for inclusion in Perl 6.

People would email Uri for membership, etc, etc per the above steps. On
selection of the team, the "Members" section would include the names of
those involved, and the "Needs" section would be marked as something
like "0 people (closed)". Then the team uses the private sublist to
design, code, etc, etc.

Thoughts?

-Nate

RE: Now and then

[Nathan Torkington]

David Grove writes:
> I'm wondering how different this is from the current setup.

Currently there's the pumpking and the pumpking decides when to
release a new version of Perl.  This exposes the pumpking to all sorts
of allegations, and potentially exposes Perl to being bought out.

When no single person can force a release through, both problems go
away.  It's distributing the current pumpking's responsibility
(integrating patches, quality control, communication and deadlines)
to more people.  This has the added benefit of hopefully avoiding
pumpking burnout.

> Points of clarification, however. QA team determines definite
> preparedness for release?

It's a joint decision.  If QA likes it, but the code person doesn't,
they have to sort that out between themselves before the release can
happen.  If the user liaison says "we've been promising this for the
last three releases, we can't make another release without it" then
the others have to listen.

But nothing can be released without QA's approval.

Nat

Re: Now and then

[Adam Turoff]

On Wed, Oct 11, 2000 at 09:41:30AM -0600, Nathan Torkington wrote:
> Then again, remember the hassles we had with the perl6-* lists?
> Nobody knew how to deal with topics that overlapped lists.  You had
> to know all the groups to decide which it was appropriate for.  Are
> these big enough hassles to suggest that perhaps the perl5-porters
> All In One list wasn't such a bad idea after all?

Perhaps.  Even though there was a lot of traffic, much of it was easy
to follow because a significant proportion of it was consistently 
titled - RFC ## (v#): Add XYZ into Perl.  That traffic is also easy
to find in the archives.

That will probably be less of an issue with a strong lack of RFC
activity during the implementation phase.  It very well could be
that anyone doing serious work is going to subscribe to perl6-all,
and the perl6-* lists exist for those who just want to listen.

Z.

Re: Now and then

[Nathan Torkington]

Uri Guttman writes:
> that resonates with MMM totally. look at the surgical team approach as
> well but updated. each group has a lead and a 2nd (and possibly 3rd) in
> charge. others in the group do work on various parts under control of
> the group leaders. support types like QA, version control, docs
> management, can be shared among groups.

I'm not sure I like the idea of a lead.  I think all three (QA,
source, user liaison) should be equal partners.  I think each group's
list should be open to public contributions.  The point is to encourage
public participation in the ongoing maintenance.

Then again, remember the hassles we had with the perl6-* lists?
Nobody knew how to deal with topics that overlapped lists.  You had
to know all the groups to decide which it was appropriate for.  Are
these big enough hassles to suggest that perhaps the perl5-porters
All In One list wasn't such a bad idea after all?

Nat

Re: Now and then

[John Porter]

David Grove wrote:
> 
> No two or more members of a single company on (QA Team|Any Team)? If 
> any team, for the purpose of development, it's not entirely logical/feasable, 
> is it? 

I think it's not feasible generally.  Maybe if you tighten up your
definition of "single company".  For example, I work for a company
with over 35000 employees all over the country.  Who knows how many
of them would want to participate in p6 development?  It shouldn't
matter, because my company has no interest in the direction p6 takes,
and would never, ever meddle in the way you fear.

Also, your limit of 2 per committee doesn't make much sense, since
a committee might only have 3 members, in which case 2 is a majority.
Make strict minority is a better spec.

-- 
John Porter

Re: Now and then

[Uri Guttman]

> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:

  NT> Implementation is different from design, and different again from
  NT> maintenance.  If we do the design, test cases, and stubbing well
  NT> enough, we could have a cast of thousands doing the implementation.

cecil b. demillions of coders.

  NT> I'm thinking about a team structure for ongoing maintenance.  Each
  NT> area (docs, stdlib, interpreter, compiler) has its own team.  A team
  NT> is only a few people: the person responsible for submitting patches,
  NT> someone responsible for keeping on top of user demands, and someone
  NT> from QA.  In some cases these roles might be shared, and there's no
  NT> law that says the same QA person couldn't be on several teams.  The
  NT> only law I'd want is that no team could be made up of people from
  NT> the same company.

that resonates with MMM totally. look at the surgical team approach as
well but updated. each group has a lead and a 2nd (and possibly 3rd) in
charge. others in the group do work on various parts under control of
the group leaders. support types like QA, version control, docs
management, can be shared among groups.

  NT> In addition to these people is a release manager, coordinating
  NT> with everyone to set realistic deadlines and ensure everyone's
  NT> talking with everyone else.  No release goes out the door until
  NT> all the teams agree that they have a Good Enough product.  This
  NT> way neither ActiveState, Microsoft, nor the Trilateral Commission
  NT> can dictate an unrealistic release date.  And this goes both ways:
  NT> if there is a dodgy release, the blame can't be pointed at just
  NT> one company.  At a team perhaps, but there can be no accusations
  NT> of coercion and manipulation.

damn, i wanted to use my trilateral connections to fork perl in my
way. all my rfc's ROOL! :)

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

RE: Now and then

[Dan Sugalski]

At 08:50 PM 10/10/00 -0500, David Grove wrote:
>Group: I have now had seventeen requests to fork perl from people other than
>"elitists" apparently joking (?) about it.

I haven't been. I don't think anyone else has either. It's not a joke, and 
it is a valid thing to do.

>The answer is ABSOLUTELY NO. Stop asking. If _YOU_ fork it, don't consider 
>yourself any advocate of Perl or this community! The problems in this 
>community are not solved by secession.

That's a rather absolutist and silly thing to say. Sometimes secession *is* 
a valid option. In some cases it's a better option. I'd far rather that 
someone with a profound difference in opinion of the direction of 
development fork and go off on their own, rather than either stay and make 
lots of folks (including themselves) miserable or having the community as a 
whole lose them.

Forking isn't bad. The world's certainly not a worse place for having all 
the various BSD and SysV Unix forks. (Most of the commercial Unices 
qualify, as do the *BSDs) Neither is it a bad place for having the GCC fork 
not all that long ago.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: Now and then

[David Grove]

On Tuesday, October 10, 2000 8:03 PM, Nathan Torkington [SMTP:[EMAIL PROTECTED]] 
wrote:
> I think we're talking about two different periods of development here.
>
> The immediate question facing us is how to structure software design.
> This is different from the ongoing maintenance of Perl.
>
> We want and need a small group to design perl6 correctly.  I can't see
> this working any other way.  Software design is a completely different
> process from maintenance, and it's unrealistic to expect the
> maintenance model (big open mailing lists, everyone says what they
> want) to work for an intently cerebral activity.
>
> Design I'm seeing as in two parts: architecture (what are the major
> components we need?) and detailed design (where each component has
> an API designed and the interactions between components resolved).
> The architecture will be partially decided by Larry, and seems best
> done by a few experienced with such things.  Detailed design seems
> appropriate for groups of 5-10 people in each area.  In both cases,
> public viewing of the proceedings is mandatory (you can read their
> messages and see their thoughts and comment in private).
>
> Implementation is different from design, and different again from
> maintenance.  If we do the design, test cases, and stubbing well
> enough, we could have a cast of thousands doing the implementation.
>
> I honestly don't see us arguing over design.  Or even over
> implementation.  The big meat of this discussion so far seems to have
> been how to prevent the ongoing maintenance of Perl from being
> coopted.
>
> I'm thinking about a team structure for ongoing maintenance.  Each
> area (docs, stdlib, interpreter, compiler) has its own team.  A team
> is only a few people: the person responsible for submitting patches,
> someone responsible for keeping on top of user demands, and someone
> from QA.  In some cases these roles might be shared, and there's no
> law that says the same QA person couldn't be on several teams.  The
> only law I'd want is that no team could be made up of people from
> the same company.
>
> In addition to these people is a release manager, coordinating with
> everyone to set realistic deadlines and ensure everyone's talking with
> everyone else.  No release goes out the door until all the teams agree
> that they have a Good Enough product.  This way neither ActiveState,
> Microsoft, nor the Trilateral Commission can dictate an unrealistic
> release date.  And this goes both ways: if there is a dodgy release,
> the blame can't be pointed at just one company.  At a team perhaps,
> but there can be no accusations of coercion and manipulation.
>
> I don't see voting having a role in any of this, except as a crude
> opinion poll for the internal equivalent of Marketing.  Voting doesn't
> work in the real world, and in an online world where you can't even
> make someone respond to your email, I see it being even less
> effective.
>
> How's this sound?
>
> Nat


Corporate and diplomatic, but worth a shot. If it even has a _chance_ at 
keeping fair play in the community, I'll support it. It apparently does, though 
I'm wondering how different this is from the current setup.

Points of clarification, however. QA team determines definite preparedness for 
release? No two or more members of a single company on (QA Team|Any Team)? If 
any team, for the purpose of development, it's not entirely logical/feasable, 
is it? For the purpose of determining the quality of a potential release or 
code fix, etc., it's one step in the right direction. Would this team be able 
to return crippled features to developers for rethinking (extending, 
embedding)?

Thanks again for your tolerance and even-handedness, Nat.

Group: I have now had seventeen requests to fork perl from people other than 
"elitists" apparently joking (?) about it. The answer is ABSOLUTELY NO. Stop 
asking. If _YOU_ fork it, don't consider yourself any advocate of Perl or this 
community! The problems in this community are not solved by secession. Even if 
it were technically feasable, it's absolutely disgusting to me, and I'll have 
no part of it. I wish it were politically correct to curse!

Now and then

[Nathan Torkington]

I think we're talking about two different periods of development here.

The immediate question facing us is how to structure software design.
This is different from the ongoing maintenance of Perl.

We want and need a small group to design perl6 correctly.  I can't see
this working any other way.  Software design is a completely different
process from maintenance, and it's unrealistic to expect the
maintenance model (big open mailing lists, everyone says what they
want) to work for an intently cerebral activity.

Design I'm seeing as in two parts: architecture (what are the major
components we need?) and detailed design (where each component has
an API designed and the interactions between components resolved).
The architecture will be partially decided by Larry, and seems best
done by a few experienced with such things.  Detailed design seems
appropriate for groups of 5-10 people in each area.  In both cases,
public viewing of the proceedings is mandatory (you can read their
messages and see their thoughts and comment in private).

Implementation is different from design, and different again from
maintenance.  If we do the design, test cases, and stubbing well
enough, we could have a cast of thousands doing the implementation.

I honestly don't see us arguing over design.  Or even over
implementation.  The big meat of this discussion so far seems to have
been how to prevent the ongoing maintenance of Perl from being
coopted.

I'm thinking about a team structure for ongoing maintenance.  Each
area (docs, stdlib, interpreter, compiler) has its own team.  A team
is only a few people: the person responsible for submitting patches,
someone responsible for keeping on top of user demands, and someone
from QA.  In some cases these roles might be shared, and there's no
law that says the same QA person couldn't be on several teams.  The
only law I'd want is that no team could be made up of people from
the same company.

In addition to these people is a release manager, coordinating with
everyone to set realistic deadlines and ensure everyone's talking with
everyone else.  No release goes out the door until all the teams agree
that they have a Good Enough product.  This way neither ActiveState,
Microsoft, nor the Trilateral Commission can dictate an unrealistic
release date.  And this goes both ways: if there is a dodgy release,
the blame can't be pointed at just one company.  At a team perhaps,
but there can be no accusations of coercion and manipulation.

I don't see voting having a role in any of this, except as a crude
opinion poll for the internal equivalent of Marketing.  Voting doesn't
work in the real world, and in an online world where you can't even
make someone respond to your email, I see it being even less
effective.

How's this sound?

Nat