From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web12.550.1581718452046890976 for ; Fri, 14 Feb 2020 14:14:12 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iKVY7dcy; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581718451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iyczYwBFWWe+ivb7wfETGlWnCDY1lflKdP3NaUdzZAg=; b=iKVY7dcykDxVIulIiIhD55bf9EbJjDDHv5G9FWCRxkVH3qnn5AXn+xKxWU7aaGygQHsJvR m4oaW9GFv1mu42CFRNXpL8JfAlWn6JTJ9Hr0PqjeNH2y86ZperKIBqlwInL1NbdQZMn8Ve cQuoAm9WmqA3dR3wRHyGZcg5vfw0kk4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-143-ZeZf827iN1q5KGLnDl0EVQ-1; Fri, 14 Feb 2020 17:14:05 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ED2DE800D53; Fri, 14 Feb 2020 22:14:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-153.ams2.redhat.com [10.36.116.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id DBD445C126; Fri, 14 Feb 2020 22:14:02 +0000 (UTC) Subject: Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6 To: devel@edk2.groups.io, sean.brogan@microsoft.com, Soumya Guptha References: <3765.1581704727843482010@groups.io> From: "Laszlo Ersek" Message-ID: <96a33178-ed1b-426f-b3e4-635647121ea4@redhat.com> Date: Fri, 14 Feb 2020 23:14:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3765.1581704727843482010@groups.io> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: ZeZf827iN1q5KGLnDl0EVQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/14/20 19:25, Sean via Groups.Io wrote: > Soumya, > I would like to add three things to community discussions especially arou= nd governance and process. >=20 > 1. RFC: The RFC process seems to get only minimal comments and a lot gets= lost in the noise of the lists.=C2=A0 There isn't a good "final" state whe= re all approved RFCs can be seen.=C2=A0 The process is entirely driven by t= he submitter and thus there is little consistency.=C2=A0 =C2=A0I wanted to = highlight another project and how they handle this. https://github.com/rust= -lang/rfcs ( https://github.com/rust-lang/rfcs ) As a casual observer it is= very easy to review their RFCs (in flight and approved/rejected) as well a= s understand how to create and submit one if so desired.=C2=A0 The tooling = is just git/github so it is familiar to the target audience and has a stron= g ability to track progress, show history, and be backed up like any code p= roject.=C2=A0 They also leverage github issue tracker for pre rfc conversat= ion and discussions. I agree that RFCs get sorely little attention from the community. ... From my personal perspective, it's not because the RFCs are not visible -- I simply don't have time to even *understand* most RFCs for their merits. For example, I checked out Microsoft's VariablePolicy slides. The design seemed systematic and I appreciated that, it's just that I couldn't bring myself to make half-cooked comments (regardless of forum), because those wouldn't do justice to the topic, and I simply couldn't commit to a deeper involvement. I can imagine that others appear to ignore several RFCs due to similar (capacity) reasons. > 2. Bugs/Features/Releases:=C2=A0 First the bug triage and scrub is not ve= ry well attended.=C2=A0 I know it is hard to get a ww audience together on = a call Personal angle again: - synchronous communication hampers my throughput - got quickly demotivated by perceiving significantly less effort from others Bug triage is a thankless job. > but i think part of the goal was to offer a public process and a place to= learn/discuss.=C2=A0 Is there a better way that still meets those goals?= =C2=A0 Secondly, the number of bugs that get discussed is pretty small and = the list of open bugzillas are grower faster than the triage effort.=C2=A0 = Third, the results are pretty minimal.=C2=A0 Usually a change in owner and = a very short comment asking the owner to look at it is the result of the tr= iage.=C2=A0 There is sometimes good conversation (assuming knowledgeable pa= rties are in attendance) but this is impractical to capture into the bugzil= la while still keeping forward progress. Can you please clarify this suggested conflict (between capturing good technical discussion in the BZ tickets, and "forward progress")? I think Bugzilla tickets are the best place to capture the focused analysis of a bug. I write a *lot* of text in Red Hat bugzillas (most of them are public, luckily!) -- I want to document my own "adventure" with the issue, even if most paths prove dead-ends in the end. How does that conflict with "forward progress"? >=C2=A0 =C2=A0Finally, as an submitter of a lot of open/unconfirmed bugs it= is not very easy to understand the owners priorities and when the bug will= be fixed and merged to master/stable tag. Agreed 100%. Lack of visibility into planning / resource allocation is the worst. I sometimes have no choice but to "shed load" (review requests etc). What I find important is to be honest about such cases, and state "sorry, you've been dropped off my queue" reasonably quickly. Leaving others hanging is one of the *worst* faces of open / distributed development. > I am happy to contribute effort to making a new process but want to under= stand if others are frustrated by this as well. Oh yes. >=20 > 3. Discussions: I wanted to know if anyone has experience with user forum= s like https://www.discourse.org/.=C2=A0 Again the rust community uses this= and it is a pretty nice interface for async communication that doesn't inv= olve mail server and client configuration challenges, corporate policies, a= nd the noise of email. (You know my opinion on email ;)) Thanks Laszlo