[edk2-devel] TianoCore Community Meeting Minutes - Feb 6

[Soumya Guptha]

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 <lersek at redhat.com> 
Sent: Friday, February 14, 2020 2:14 PM
To: devel at edk2.groups.io; sean.brogan at microsoft.com; Guptha, Soumya K <soumya.k.guptha at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-