develooper Front page | perl.perl5.porters | Postings from July 2014

anti-bike^WProductive Discussion Workflow ideas ( was: Re New featureproposal : <<>> to disable magic open of ARGV )

Thread Next
Kent Fredric
July 26, 2014 23:24
anti-bike^WProductive Discussion Workflow ideas ( was: Re New featureproposal : <<>> to disable magic open of ARGV )
Message ID:
On 27 July 2014 10:38, Ricardo Signes <> wrote:

> Here's my counter-proposal on bike-shedding:   no more using the phrase
> bike-shedding.  It's now used to mean "somebody wants to talk about
> something
> where I think I'm already right," and it's too emotionally charged.  If you
> think someone is debating pointless trivia, suggesting changes of no
> consequence, or can't see the forest for the trees, point out the specific
> problematic behavior.
> There is absolutely no way on Earth that I am going along with "apply or
> don't
> apply, but never discuss," though.

I do mostly agree. My affirmation re avoiding unproductive discussion was
not intended to convey dissent for discussion entirely, its just easy to
have the discussion get side tracked into fractal permutations of counter

Its not that the counter proposals and problem solving itself is /bad/ per
say, its just as the volume of information grows, it becomes progressively
harder to work out what is being discussed.

Its the sort of scenario where a wiki could come in handy, and then instead
of having infinite fractals which are hard to track, you have a hierarchy,
or something:

[ General Kind of Proposal = What we want to do ]
  - [ Specific Proposed Implementation 1 ]
       - Proposed by Matthew
       - Approved by Alice, Bob, Jill               [ >> reasons ]
       - Disproved by Greg, Hannah and Mary [ >> reasons ]
       - Countered by Charlie[2]                      [ >> reasons ]

  - [ Specific Proposed Implementation 2 ]
       - Proposed by Charlie
       - Approved by Greg, Hannah and Mary [ >> reasons ]
       - Disproved by Alice, Bob, Jill              [ >> reasons ]

The idea being each proposal is written imperfectly, and then revised
progressively in response to feedback, and people on the sidelines who want
to voice their approval without feedback can do so.

And the revised proposal should incorporate a list of pros/cons the
proposal implies, in response to feedback.

They that proposes is primary on revising the proposal, and any approved
moderators and anyone they appoint to revise it on their behalf.

TL;DR => Discussion and feedback good, but too much discussion and feedback
simply inspires lack of interest and the proposals don't get developed to
the point of being useful ideas due to an onslaught of me-too counter



Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About