Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6
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 Sent: Friday, February 14, 2020 2:14 PM To: devel@edk2.groups.io; sean.bro...@microsoft.com; Guptha, Soumya K 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6
On 02/15/20 00:24, Sean via Groups.Io wrote: > On Fri, Feb 14, 2020 at 02:14 PM, Laszlo Ersek wrote: > >> >> 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"? > > By this i mean during the meetings it is impossible to capture the > conversation, be involved in the conversation, update the bugzilla, > and still move fast enough. In general I do believe putting detailed > information in the bugzilla is great and not in conflict with forward > progress but in the context of the meeting it is not practical. Ah, agreed. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54543): https://edk2.groups.io/g/devel/message/54543 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6
On Fri, Feb 14, 2020 at 02:14 PM, Laszlo Ersek wrote: > > 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"? By this i mean during the meetings it is impossible to capture the conversation, be involved in the conversation, update the bugzilla, and still move fast enough. In general I do believe putting detailed information in the bugzilla is great and not in conflict with forward progress but in the context of the meeting it is not practical. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54487): https://edk2.groups.io/g/devel/message/54487 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6
On 02/14/20 19:50, Rebecca Cran wrote: > On 2/14/20 11:25 AM, Sean via Groups.Io wrote: > >> >> 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. > > > For real-time communications, I think many organizations now use Slack > (https://slack.com). In that case, the problem they have is not the tool (whatever it is), but the fact that they need to communicate in real time. ;) Sorry, couldn't resist! Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54476): https://edk2.groups.io/g/devel/message/54476 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] -=-=-=-=-=-=-=-=-=-=-=-
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 (#54475): https://edk2.groups.io/g/devel/message/54475 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6
On 2/14/20 11:25 AM, Sean via Groups.Io wrote: 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. For real-time communications, I think many organizations now use Slack (https://slack.com). -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54471): https://edk2.groups.io/g/devel/message/54471 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6
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. 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 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. 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. I am happy to contribute effort to making a new process but want to understand if others are frustrated by this as well. 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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#54470): https://edk2.groups.io/g/devel/message/54470 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] -=-=-=-=-=-=-=-=-=-=-=-
