[TCLCORE] Re: The timing of votes - (was TIP 5 VOTE)

[Jim I. <ji...@ap...>]

Hi, folks...

Eric's call for vote brings up another point we probably need to set some
conventions for.  The history of this TIP will have run its course in 1
week, if we follow Eric's suggested schedule, proposed first on 10/10/00,
and with a final vote on 10/17/00.

While in this case, I understand that part of Eric's goal is to "push the
TIP process", I think this is pushing it a bit fast.  I am not convinced
that Eric & George couldn't have reached consensus by further discussion.
But that aside, there are a lot of busy weeks in the year in which I
wouldn't have ANY time to think on issues not directly related to my day
job.  I am sure that this is true of many of us.

I see no reason why the team's response to a TIP needs to go this fast.  I
don't think any reasonable person will get bothered if it takes two or three
weeks to talk out a proposal, particularly if there seems to be an ongoing
discussion.  We are all busy people, and if we allow the process to be
pushed too fast by the (understandable but not imperative) desires of the
submitters, we will just end up making bad decisions.

I also think that discussions - especially e-mail ones - often get heated
beyond the intent of the parties involved, and a few days to sit back and
think can bring a much better resolution than plunging straight from
deadlock to a vote.  In this light, I think the notion that the summary of
views should be followed by NO more discussion, but only a vote, is not
likely to lead to good decisions either.

One way I can think of to balance the need to proceed in a regular &
predictable way on TIP's, and to allow for productive deliberation, is to
set a MINIMUM time on discussions. Something on the order of two weeks seems
good, extendable if the discussion warrants.  This way, if the discussion
gets heated, the initial furor will have time to die down, people can go
away for the weekend, think about it more cooly, and then resume in a better
mode.  

Also, most business trips are ~1 week, so this will increase the chances
that everybody will have a decent chunk of time to think about it even if
they have to go away.  And given a weeks advance notice, I can almost always
find some time to think about an issue - leaving a week to work out the
results of such thoughts with the rest of the group.

If people can think of another mechanism to achieve this same end, that
would be great.  This one seems okay to me, but I am not over committed to
it...

The main point is that there is a very understandable impatience on the part
of proposal submitters - a desire that they get an IMMEDIATE decision on
their idea.  This is human nature.  But knowing that, it is all the more
important that we have a well defined break on this impatience, that is
known up front, to help us ensure the quality of our discussions.

Jim




> 
> Jeff asked me to send this directly myself, as I am the author of the
> proposal.
> 
> It seems that discussions over TIP #5, "Make TkClassProcs and
> TkSetClassProcs public," have reached their productive end.  No new
> arguments are being made.  Since there was one objection (from George
> Howlett), we must proceed to a full vote of the Tcl Core Team.
> 
> The proposal may be read from the archives of this mailing list at:
> 
> http://dev.scriptics.com/lists/tclcore/2000/10/msg00039.html
> 
> There is one addition to the proposal:  the API's
> Tk_GetWindowCallbacks and Tk_GetWindowCallback will be added, as
> requested, to provide a complete, symmetric set of API's.
> 
> The objection to the proposal was:
> 
> The proposal introduces complexity prematurely.  Nothing is yet
> known about what features will be required of future widgets.
> There is no point in creating a more complex system, since there
> is no guarantee that anything we come up with will meet the
> requirements anyway.  Making the API more general now will just be
> code bloat.
> 
> Instead, the API should be made public as is.  It is more simple,
> and it fits the current needs.
> 
> 
> As author of the proposal, I counter this objection with:
> 
> It's true that we cannot be certain that any more general API we
> design now will be able to meet future needs.  However, I think it
> is reasonable to expect that if we do extend the callback
> mechanism, new callbacks will be implemented in the same way that
> existing callbacks are.  The proposal allows for extensions of
> that form gracefully.
> 
> Likewise, I think it is likely that we will extend to callback
> mechanism, as extension writers work to integrate other widget
> toolkits with Tk and shortcomings of the current system are
> exposed.
> 
> 
> If I have misstated the objection, or if there are other objections,
> please say so now.  Please do not argue about which viewpoint is
> correct at this time.  Simply state any corrections.  Barring any
> corrections, voting for this proposal will commence 1300 PST
> 2000-Oct-13, and will conclude at 1000 PST 2000-Oct-17.  I will send
> an additional reminder when the voting period begins tomorrow.
> 
> When casting your vote, please mail it to tc...@aj..., with
> the subject "TIP 5 VOTE" (responding to this message will produce that
> subject line), and include a statement of "yes" or "no", and, if you wish,
> why you have voted as you have.
> 
> Thanks,
> 
> Eric Melski                            The Other Tcl Guy
> ericm at ajubasolutions.com            Ajuba Solutions
> 
> --
> The TclCore mailing list is sponsored by Ajuba Solutions
> To unsubscribe:  email tcl...@aj... with the
> word UNSUBSCRIBE as the subject.
> 
> 

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.