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

["Laszlo Ersek" <lersek@redhat.com>]

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