Mailing List Archive

On Wed, Jun 23, 2021 at 06:43:22AM +0200, Branislav Zahradn?k wrote:
> Reading discussion about RFCs, main concerns
>
> - up-to-date status is hard to track
> - rejected rfcs and/or parts are hard to track

This is partly my fault for being behind on acting upon things - last
Wednesday we added an agenda item for the next PSC meeting. That happened
on Friday (the timing is for Rik, who has the most scheduling constraints)
However Friday afternoon for me means that likely *my* actions don't happen
until Monday, and then on Monday I wasn't feeling great, so I only really
caught up this morning.

(Ended up being ambushed by an unexpected siesta that was hiding somewhere
near the sofa. As in, I merely sat down, but then found myself an hour
later waking up feeling terrible)

https://github.com/Perl/RFCs

* is now up to date, with tables with statuses
* should be easy to keep accurate, as things don't change hourly


> Tracking in mailing list still expects reading mailing list and remember
> every piece of discussion.

The intent remains that the author of the RFC summarises the discussion
*in* the RFC.

Switching to PRs with line-by-line commenting *still* generates O(n) scans
of discussion, just like a mailing list.

> Reasonably prepared RFCs (looks like I'm excluding myself already), even if
> rejected, should be
> preserved in rfc repository to prevent useless discussions.

We are doing this.

> There should also be some written vision guidelines to prevent comments
> like "this is not perlish enough (because I don't understand it)" or long
> discussions about name of defer (when it was FINALLY).

Yes, I've been working on the draft of "what is perlish" (in my head)

I don't know if the new PSC want me to continue, or how they want to handle
this. The early election close came as a bit of surprise to everyone, *and*
the timing means that not everyone has been awake at the same time yet.

As to discussions - this is really hard. Wherever we run RFCs (mailing list
or GitHub comments) we can't exclude participants for wanting to contribute
"in the wrong way", as long as they are civil about it. Any attempt to
forcibly impose "moderation" is going to look like censorship or
dictatorship to some people, and cause more digression about process than
would be saved by ignoring the ramblings.

Some people are going to digress. Worse, some people are going to think
that they *are* saying useful things when most others agree that they are
not. We don't have a closed mailing list (or closed issue tracker), so we
can't "vote people off" and eject them because we think that they are a
waste of time.

Nicholas Clark

On Wed, 23 Jun 2021 at 09:43, Nicholas Clark <nick@ccl4.org> wrote:

>
> Switching to PRs with line-by-line commenting *still* generates O(n) scans
> of discussion, just like a mailing list.
>

Not necessary, you can update PR and mark comment as resolved.
One still can do such scan but resolving comment is usually enough even in
code reviews


>
> > Reasonably prepared RFCs (looks like I'm excluding myself already), even
> if
> > rejected, should be
> > preserved in rfc repository to prevent useless discussions.
>
> We are doing this.
>

I may use wrong terms ... even rejected ideas should be there.


>
> > There should also be some written vision guidelines to prevent comments
> > like "this is not perlish enough (because I don't understand it)" or long
> > discussions about name of defer (when it was FINALLY).
>
> Yes, I've been working on the draft of "what is perlish" (in my head)
>
> I don't know if the new PSC want me to continue, or how they want to handle
> this. The early election close came as a bit of surprise to everyone, *and*
> the timing means that not everyone has been awake at the same time yet.
>
> As to discussions - this is really hard. Wherever we run RFCs (mailing list
> or GitHub comments) we can't exclude participants for wanting to contribute
> "in the wrong way", as long as they are civil about it. Any attempt to
> forcibly impose "moderation" is going to look like censorship or
> dictatorship to some people, and cause more digression about process than
> would be saved by ignoring the ramblings.
>
>
goal is not to exclude, goal is to provide guidelines and prepare
additional advocacy.
(and of course, "it's not perlish" should not be veto or a synonym for "I
don't and don't want to understand it"

Being different is a way to evolve, to adapt. From language usage point of
view, perlish may be
only culture (btw, that's reason why I think multi-alias loop should be
behind feature).
Perl way should save effort and money. Without that, perl will be dead.
(few more EP will follow ...)

Some people are going to digress. Worse, some people are going to think
> that they *are* saying useful things when most others agree that they are
> not. We don't have a closed mailing list (or closed issue tracker), so we
> can't "vote people off" and eject them because we think that they are a
> waste of time.
>

Well, that's evolution. Humans are disgusting small creatures (from
dinosaur's point of view),
yet someone adopted and survived, someone extinguished.

Way how p5p will handle digress may signal lack or excess of group-thinking.


>
> Nicholas Clark
>