[Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

+1 to this. First and foremost we're looking for a way to summarize and document the outcome of discussions and decisions made. That's what QUIPs are for.

Arguing about whether gerrit is the perfect tool for reviewing QUIPs is besides the point. It is a tool that'll work better than email discussions (as we're also seeing in this thread), and it's a tool we all are using daily and that we know. And btw, it's being used for documentation changes and review as well.  And I'd rather work with gerrit (with all it's deficiencies) than introduce yet another separate tool that doesn't fit into our workflow.

Cheers,
Lars

On 21/11/16 21:11, "Development on behalf of André Pönitz" <development-bounces+lars.knoll=qt.io at qt-project.org on behalf of apoenitz at t-online.de> wrote:

    On Mon, Nov 21, 2016 at 11:06:52AM +0000, Edward Welbourne wrote:
    > Giuseppe D'Angelo:
    > >> I would also like to point out that, despite we have a repository, we
    > >> still don't have a tool for properly discussing the actual content of
    > >> QUIPs.
    > >>
    > >> * Gerrit does not work because comments cannot be threaded, they
    > >>   don't stick to multiple reviews, and they can be ignored
    > >> * Email does not work (it may work for the overall direction, but not
    > >>   for the in depth discussion) because a single message may cover
    > >>   multiple discussion points, disrupting the threading, and
    > >>   discussion points can get ignored (*)
    > 
    > All of which plays into my desire to introduce you all to Critic [0]
    
    Guys,
    
    the idea of QUIPs was to *fix* a problem, namely the current inability
    to pinpoint results of mailing list discussion. This *is* a problem for
    the Project, as lazy consensus on the mailing list is *the* official
    decision making process in the Qt Governance model, but it works in
    practice rather accidentally, if at all.
    
    Discussions are observed to deteriorate, develop into completely
    unrelated discussions, and even if something appears like consensus or
    the discussion dies, it typically turns out that different people think
    differently about what the consensus actually was, and the discussion
    re-starts half a year later.
    
    You both nicely demonstrate that this problem exist, thank you for that,
    but beyond that this particular sub-discussion misses the point.
    QUIPs were not meant to require new or different tooling, and I still
    believe such will be needed.
    
    The rough idea is that a topic is presented as usual on the mailing
    list, and when someone, usually the original proponent, gets the feeling
    that the usual rounds of bike-shedding, trolling and name-calling is
    over, and the occasional sensible arguments all have been heard, writes
    up what appears like a potential consensus and puts that on Gerrit,
    where some review process commences.
    
    The only difference to a normal review process I'd like to see would be
    a *much* higher bar for approval, to ensure that QUIPs are really close
    to consensus and to ensure some consistency within the set of QUIPs.
    
    None of this requires new tools, certainly not the bootstrapping of
    the first QUIP. There's also nothing changing processes, so everybody
    will be free to continue to present his views on his favourite tools
    in the future, but for now I'd really like to get this here done.
    
    IMNSHO it boils down to the question: Does anybody have any fundamental
    problem with main idea of having documents summarizing the lazy consensus
    of certain mailing list discussions? If not I'd call that a lazy
    consensus and would ask to proceed with reviewing the final wording
    on Gerrit.
    
    Andre' 
    
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    http://lists.qt-project.org/mailman/listinfo/development