From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] TianoCore Community Meeting Minutes - Feb 6 To: Soumya Guptha ,devel@edk2.groups.io From: "Sean" X-Originating-Location: Redmond, Washington, US (50.35.74.15) X-Originating-Platform: Windows Chrome 80 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Fri, 14 Feb 2020 10:25:27 -0800 References: In-Reply-To: Message-ID: <3765.1581704727843482010@groups.io> Content-Type: multipart/alternative; boundary="9rL3LaPM463ZQwwrM05g" --9rL3LaPM463ZQwwrM05g Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Soumya, I would like to add three things to community discussions especially aroun= d 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.=C2=A0 There isn't a good "final" state wher= e all approved RFCs can be seen.=C2=A0 The process is entirely driven by th= e submitter and thus there is little consistency.=C2=A0 =C2=A0I wanted to h= ighlight 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.=C2=A0 The tooling i= s 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 pr= oject.=C2=A0 They also leverage github issue tracker for pre rfc conversati= on and discussions. 2. Bugs/Features/Releases:=C2=A0 First the bug triage and scrub is not ver= y well attended.=C2=A0 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 plac= e to learn/discuss.=C2=A0 Is there a better way that still meets those goal= s?=C2=A0 Secondly, the number of bugs that get discussed is pretty small an= d 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 t= he triage.=C2=A0 There is sometimes good conversation (assuming knowledgeab= le parties are in attendance) but this is impractical to capture into the b= ugzilla while still keeping forward progress.=C2=A0 =C2=A0Finally, as an su= bmitter 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 wan= t 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/.=C2=A0 Again the rust community uses this = and it is a pretty nice interface for async communication that doesn't invo= lve mail server and client configuration challenges, corporate policies, an= d the noise of email. --9rL3LaPM463ZQwwrM05g Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Soumya,
I would like to add three things to community discussions espe= cially around governance and process.

1. RFC: The RFC process se= ems to get only minimal comments and a lot gets lost in the noise of the li= sts.  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 an= d how they handle this.  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 und= erstand how to create and submit one if so desired.  The tooling is ju= st git/github so it is familiar to the target audience and has a strong abi= lity to track progress, show history, and be backed up like any code projec= t.  They also leverage github issue tracker for pre rfc conversation a= nd discussions.     

2. Bugs/Features/Releases:&n= bsp; 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 pret= ty 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 someti= mes good conversation (assuming knowledgeable parties are in attendance) bu= t this is impractical to capture into the bugzilla while still keeping forw= ard progress.   Finally, as an submitter of a lot of open/unconfi= rmed 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 contri= bute effort to making a new process but want to understand if others are fr= ustrated by this as well.  

3. Discussions: I wanted t= o 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 communicat= ion that doesn't involve mail server and client configuration challenges, c= orporate policies, and the noise of email.   --9rL3LaPM463ZQwwrM05g--