Hi Sean and Laszlo, Great points. We should discuss with the community around the process and the governance. I will add these to our upcoming community meeting to brainstorm.
Thanks, Soumya -----Original Message----- From: Laszlo Ersek <ler...@redhat.com> Sent: Friday, February 14, 2020 2:14 PM To: devel@edk2.groups.io; sean.bro...@microsoft.com; Guptha, Soumya K <soumya.k.gup...@intel.com> Subject: Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6 On 02/14/20 19:25, Sean via Groups.Io wrote: > Soumya, > I would like to add three things to community discussions especially around > governance and process. > > 1. RFC: The RFC process seems to get only minimal comments and a lot gets > lost in the noise of the lists. There isn't a good "final" state where all > approved RFCs can be seen. The process is entirely driven by the submitter > and thus there is little consistency. I 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 as understand how > to create and submit one if so desired. The tooling is just git/github so it > is familiar to the target audience and has a strong ability to track > progress, show history, and be backed up like any code project. They also > leverage github issue tracker for pre rfc conversation 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: First the bug triage and scrub is not very > well attended. 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. Is there a better way that still meets those goals? > Secondly, the number of bugs that get discussed is pretty small and the list > of open bugzillas are grower faster than the triage effort. Third, the > results are pretty minimal. Usually a change in owner and a very short > comment asking the owner to look at it is the result of the triage. There is > sometimes good conversation (assuming knowledgeable parties are in > attendance) but this is impractical to capture into the bugzilla 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"? > Finally, 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 > understand if others are frustrated by this as well. Oh yes. > > 3. Discussions: I wanted to know if anyone has experience with user forums > like https://www.discourse.org/. Again the rust community uses this and it > is a pretty nice interface for async communication that doesn't involve mail > server and client configuration challenges, corporate policies, and the noise > of email. (You know my opinion on email ;)) Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54583): https://edk2.groups.io/g/devel/message/54583 Mute This Topic: https://groups.io/mt/71050210/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
