Re: [hybi] Resolving Issue 11 - Amateur programmer requirement [was: Extensibility mechanisms?]

[Ian Fette (イアンフェッティ) <[e-mail]>]

The amateur programmer argument keeps coming up. Search google for hybi
amateur programmer. It's been raised as an argument against suggestions that
are meant to help the protocol scale, it's been raised in discussions of
keepalives, it's been raised in multiple framing discussions... I'm not
arguing it's a great construct. I don't actually agree that we should be
designing for an amateur programmer. What I'm saying is that I do believe
that this issue being outstanding is preventing further progress on other
issues, so I want to see it put to rest.

On Thu, Jul 22, 2010 at 8:02 PM, Robert Sayre <[e-mail]> wrote:

> ----- Original Message -----
> >
> > 4677 seems to indicate that voting isn't the way to go, but instead
> > the chairs should direct the group towards rough consensus. I'm not
> > sure we will ever make everyone happy, but given the number of +1's on
> > the thread I am hopeful we might have "rough consensus" and make a
> > large number of people happy on resolving this issue. Are the chairs
> > comfortable in declaring rough consensus on this issue?
> >
> >
> > If not, looking at 6.5 of 2026 it seems to indicate that the Area
> > Director acts as an arbiter when the group / chairs cannot bring the
> > group to rough consensus. How do we move forward on this?
>
> It is better for the WG to just handle it. Those provisions are basically
> failure states.
>
>
> >
> >
> > I think it is important that this issue get resolved
>
> Well, I'm not sure. The "amateur programmer" is a pretty terrible
> construct.
>
> It's unmeasurable and untestable, so it makes no sense as a requirement.
> The only way to find out whether hobbyists will be interested in writing
> servers is to finish the standard and see what they do. It's ultimately not
> that interesting though--many successful standards have relatively few
> implementations that everyone relies on.
>
> Any argument for simplicity probably has a better rationale than the needs
> of an imaginary "amateur programmer." Let's stick to substance.
>
> - Rob
>