On Wednesday, October 04, 2000 4:19 PM, Nathan Wiger [SMTP:[EMAIL PROTECTED]]
wrote:
> Adam Turoff wrote:
> >
> > RFC Improvement #1: All updated RFCs must contain a CHANGES section.
> >
> > RFC Improvement #2: All updated RFCs must contain a synopsis of
> > relevant discussion, including opposing views.
> >
> > RFC Improvement #3: All final RFCs must contain a discussion of why
> > they are finalized.
> >
> > RFC Improvement #4: Each working group may define more stringent
> > acceptance
> > criteria for RFCs. -licensing doesn't care
> > about including test plans, and -qa doesn't care about
> > redistribution considerations.
> >
> > RFC Improvement #5: An working grouup chair can cause an RFC to be
> > withdrawn from condideration if it is off-topic
> > or simply rehashing old issues. This is to keep
> > the brainstorm-to-proposal ratio close to zero when
> > rampant brainstorming is not desired.
>
> Excellent. Another one, which has informally been done sometimes:
>
> RFC Improvement #2a: A link to the mail discussion archives should
> be provided for each revision.
>
> And *possibly*: Somebody should be able to pre-scan them. Not for
> content ("bad idea"), but to make sure they fit the format and also
> don't rehash already open or previously covered issues. This is on the
> dangerous edge of being facist though, and I'm not going to press the
> issue if others dislike it (I'm not sure I like it myself).
>
> > A modified RFC process should be in place for Perl6, where it fits.
> > And it should not be a process that generates 150+submissions/month
> > of wildly varying quality.
>
> Agreed. That would make RFC's most painful, un-fun, and self-defeating.
>
> -Nate
As long as the word "relevant" is prevalent in #2, this makes sense.
Referencing "nonsense", whose definition should be thoughtfully determined by
the individual (not just non-opposing views), would make the whole revision
irrelevant.
