If you are interested, I have a presentation: how Apache works :) I would be more than happy to join with my "member/director/contributor" hat :)
Regards JB On Thu, Apr 4, 2024 at 4:45 PM Brian Olsen <bitsondata...@gmail.com> wrote: > > That seems like a good start. I do agree there needs to be a better way to > promote engagement among other members. > > Perhaps I can do my next LinkedIn show describing the review process, how > Apache works, how to get started, and what NOT to do when submitting a PR. > > This will likely translate into a good list and set of pages for the docs. Or > an update to some existing ones. > > Would you like to join me for an episode and perhaps we can bring on a PMC > member or two of anyone is interested? > > On Thu, Apr 4, 2024 at 8:14 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: >> >> Hi Brian, >> >> Yeah, I agree with your points. That's why I would like to create a PR >> as a discussion base (that we can update thanks to everyone's >> comments). >> >> 1. I think we already have a consensus about "stale issue/PR" reminder. >> 2. The concern is more about "assign/reviewer list". Rethinking this >> point, actually, we can address this with the 1: if we have reminder >> in stale PR, then someone can engage. >> >> So, I propose to start with 1, and experiment/see how it works. >> >> Regards >> JB >> >> On Thu, Apr 4, 2024 at 1:26 PM Brian Olsen <bitsondata...@gmail.com> wrote: >> > >> > I think you both (JB and Ryan) have valid points. >> > >> > JB there absolutely is a need to address the scalability issue and we need >> > to come up with a solution. I doubt there’s any disagreement that rising >> > stale issues in the project should be ignored. >> > >> > Ryan’s concern also has merit from a different angle that could lead to >> > similar outcomes (stale PRs) with the current proposed solution, as >> > ownership while establishing and growing responsibility, could lead to >> > fiefdoms. >> > >> > There’s clearly some support for a solution and so submitting the proposal >> > as a more tangible PR is a good idea. At that point we can further revise >> > this solution to account for both concerns. This also would be a good one >> > to discuss in realtime at a community sync. >> > >> > Thanks for the edited here! >> > >> > Bits >> > >> > On Thu, Apr 4, 2024 at 4:12 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> > wrote: >> >> >> >> Anyway, I'm preparing a PR to illustrate the proposal. >> >> >> >> Regards >> >> JB >> >> >> >> On Thu, Apr 4, 2024 at 10:59 AM Ajantha Bhat <ajanthab...@gmail.com> >> >> wrote: >> >> > >> >> > Additionally, I propose allocating a brief 5-10 minute segment during >> >> > each Iceberg community sync. >> >> > During this time, attendees can highlight any pull requests needing >> >> > attention. >> >> > In cases where a pull request has become stagnant due to a lack of >> >> > reviews, committers can step forward to offer assistance by conducting >> >> > reviews and aiding in its resolution. >> >> > >> >> > - Ajantha >> >> > >> >> > On Wed, Mar 27, 2024 at 12:06 PM Jean-Baptiste Onofré >> >> > <j...@nanthrax.net> wrote: >> >> >> >> >> >> By the way, I worked on a Python program that generate a report >> >> >> containing: >> >> >> - GitHub Issues >> >> >> - Created since more than 6 months >> >> >> - Without assignee >> >> >> - Without activity (comment) since more than 7 days >> >> >> - GitHub PRs >> >> >> - Created since more than 6 months >> >> >> - Without reviewer >> >> >> - With a single reviewer >> >> >> - Without activity (comment, etc) since more than 7 days >> >> >> >> >> >> The report is a HTML page. I will send it on this thread today or >> >> >> tomorrow for review. >> >> >> >> >> >> For now, I only generate the HTML (locally on the machine), but it >> >> >> would be possible to publish on website or automatically (cron) send >> >> >> on the dev mailing list. >> >> >> >> >> >> Regards >> >> >> JB >> >> >> >> >> >> On Wed, Mar 27, 2024 at 6:57 AM Jean-Baptiste Onofré >> >> >> <j...@nanthrax.net> wrote: >> >> >> > >> >> >> > Adding a group of people as reviewers doesn't block others from help >> >> >> > and review (and it doesn't change what we do now). I don't see how >> >> >> > it's different to today, just having default people reviewing, adding >> >> >> > new people. >> >> >> > Actually, we clearly have today a bunch of PRs stale just due to lack >> >> >> > of reviewers. From a community standard, I'm also concerned that a >> >> >> > lot >> >> >> > of PR is waiting for review from the same people: that is a concern >> >> >> > for community engagement. If we have 3 persons that should >> >> >> > review/approve 90% of the PRs, it doesn't scale, it doesn't engage >> >> >> > the >> >> >> > community, other committers/PMC members might be feeling "untrusted". >> >> >> > >> >> >> > So the idea is actually to grow the community: the group of reviewers >> >> >> > can invite other people to review (having default reviewers on some >> >> >> > modules doesn't block adding others). We have several examples of >> >> >> > Apache projects where it works fine (Apache Beam is an example, we >> >> >> > increased the community engagement thanks to feedback from reviewer >> >> >> > pretty quickly instead of stale for a while and contributors give up >> >> >> > due to no response). >> >> >> > >> >> >> > Anyway, I propose to update my proposal this way: >> >> >> > 1. I update the stale PR periodical reminder (every week) >> >> >> > 2. I don't add reviewers yml, but if a PR doesn't have reviewer after >> >> >> > a week, I send a report on the dev mailing list listing all stale and >> >> >> > no review started PRs) >> >> >> > >> >> >> > Regards >> >> >> > JB >> >> >> > >> >> >> > On Tue, Mar 26, 2024 at 5:03 PM Ryan Blue <b...@tabular.io> wrote: >> >> >> > > >> >> >> > > Sorry, I'm a strong -1 for having owners or standard reviewers. >> >> >> > > >> >> >> > > In this community, we've always taken the stance that anyone >> >> >> > > should be able to jump in and help. Having assigned owners may >> >> >> > > seem like a good idea, but it actually prevents other people from >> >> >> > > volunteering and getting involved. This is also why we don't >> >> >> > > assign issues to individuals -- they often don't end up submitting >> >> >> > > a PR and it prevents other people from contributing. Having an >> >> >> > > assigned owner gives the impression that the responsibility is on >> >> >> > > a particular individual, making other people that are capable of >> >> >> > > reviewing not pay attention. I think this will slow down the >> >> >> > > community and I don't think it is a good idea. >> >> >> > > >> >> >> > > Ryan >> >> >> > > >> >> >> > > On Tue, Mar 26, 2024 at 6:36 AM Ajantha Bhat >> >> >> > > <ajanthab...@gmail.com> wrote: >> >> >> > >> >> >> >> > >> +1 for having multiple PR review owners per module/label. >> >> >> > >> >> >> >> > >> Having module owners can accelerate PR processing. For instance, >> >> >> > >> I'm awaiting feedback on a Spark action for computing partition >> >> >> > >> stats (https://github.com/apache/iceberg/pull/9437). Currently, >> >> >> > >> only Anton is reviewing, which may cause delays if he's occupied. >> >> >> > >> In my opinion, having multiple module owners would enable >> >> >> > >> developers to seek feedback more efficiently. >> >> >> > >> >> >> >> > >> - Ajantha >> >> >> > >> >> >> >> > >> On Thu, Mar 21, 2024 at 11:11 PM Jean-Baptiste Onofré >> >> >> > >> <j...@nanthrax.net> wrote: >> >> >> > >>> >> >> >> > >>> Hi folks >> >> >> > >>> >> >> >> > >>> Now that we have the proposal process "merged", I will create >> >> >> > >>> the PR >> >> >> > >>> about reviewers and update stale job. >> >> >> > >>> >> >> >> > >>> I should have the PR tomorrow for review. >> >> >> > >>> >> >> >> > >>> Thanks ! >> >> >> > >>> Regards >> >> >> > >>> JB >> >> >> > >>> >> >> >> > >>> On Thu, Mar 21, 2024 at 9:55 AM Jean-Baptiste Onofré >> >> >> > >>> <j...@nanthrax.net> wrote: >> >> >> > >>> > >> >> >> > >>> > Hi Dan >> >> >> > >>> > >> >> >> > >>> > Yes, I saw you merged it, that's great. >> >> >> > >>> > >> >> >> > >>> > I will move forward on the "stale bot" stuff. >> >> >> > >>> > >> >> >> > >>> > Thanks ! >> >> >> > >>> > Regards >> >> >> > >>> > JB >> >> >> > >>> > >> >> >> > >>> > On Wed, Mar 20, 2024 at 8:48 PM Daniel Weeks >> >> >> > >>> > <dwe...@apache.org> wrote: >> >> >> > >>> > > >> >> >> > >>> > > Hey JB, apologies for combining these two things in the same >> >> >> > >>> > > thread, but we got enough eyes on the first PR and I went >> >> >> > >>> > > ahead and merged i >> >> >> > >>> > > >> >> >> > >>> > > If you want to put together the PR for your proposed >> >> >> > >>> > > changes, we can get looking at that. >> >> >> > >>> > > >> >> >> > >>> > > We'll also need to backfill the existing proposals and >> >> >> > >>> > > update the website to have a link to the label. (Will work >> >> >> > >>> > > with you and Bits on that) >> >> >> > >>> > > >> >> >> > >>> > > Thanks, >> >> >> > >>> > > -Dan >> >> >> > >>> > > >> >> >> > >>> > > >> >> >> > >>> > > >> >> >> > >>> > > On Wed, Mar 20, 2024 at 10:01 AM Jean-Baptiste Onofré >> >> >> > >>> > > <j...@nanthrax.net> wrote: >> >> >> > >>> > >> >> >> >> > >>> > >> Hi Fokko >> >> >> > >>> > >> >> >> >> > >>> > >> I think combining Dan's proposal about "proposal process" >> >> >> > >>> > >> and this >> >> >> > >>> > >> proposal about "PR flows" would be helpful for the project >> >> >> > >>> > >> (to track >> >> >> > >>> > >> the proposals and avoid "stale" PRs/proposals). >> >> >> > >>> > >> >> >> >> > >>> > >> If PMC members are OK, I'm ready to help to set this up :) >> >> >> > >>> > >> >> >> >> > >>> > >> Thanks >> >> >> > >>> > >> Regards >> >> >> > >>> > >> JB >> >> >> > >>> > >> >> >> >> > >>> > >> On Wed, Mar 20, 2024 at 12:27 PM Fokko Driesprong >> >> >> > >>> > >> <fo...@apache.org> wrote: >> >> >> > >>> > >> > >> >> >> > >>> > >> > Hey everyone, >> >> >> > >>> > >> > >> >> >> > >>> > >> > This is a gentle bump from my end on this thread since I >> >> >> > >>> > >> > like the idea. Several people have already approved Dan's >> >> >> > >>> > >> > PR about formalizing the proposal process. Are there any >> >> >> > >>> > >> > questions or concerns from the PMC before adopting this? >> >> >> > >>> > >> > >> >> >> > >>> > >> > Kind regards, >> >> >> > >>> > >> > Fokko Driesprong >> >> >> > >>> > >> > >> >> >> > >>> > >> > Op wo 13 mrt 2024 om 13:17 schreef Renjie Liu >> >> >> > >>> > >> > <liurenjie2...@gmail.com>: >> >> >> > >>> > >> >> >> >> >> > >>> > >> >> Hi, JB: >> >> >> > >>> > >> >> >> >> >> > >>> > >> >> Your proposal looks great to me. We should definitely >> >> >> > >>> > >> >> have a vote for a proposal impacting the spec, and the >> >> >> > >>> > >> >> model is great. >> >> >> > >>> > >> >> >> >> >> > >>> > >> >> On Tue, Mar 12, 2024 at 10:55 PM Jean-Baptiste Onofré >> >> >> > >>> > >> >> <j...@nanthrax.net> wrote: >> >> >> > >>> > >> >>> >> >> >> > >>> > >> >>> Hi >> >> >> > >>> > >> >>> >> >> >> > >>> > >> >>> I think a vote would be necessary only if we don't have >> >> >> > >>> > >> >>> consensus on a >> >> >> > >>> > >> >>> proposal. If anyone is OK with the proposal (no clear >> >> >> > >>> > >> >>> "concern" in the >> >> >> > >>> > >> >>> doc and/or the GitHub issue), a vote is not required. >> >> >> > >>> > >> >>> That said, any proposal impacting a spec should be >> >> >> > >>> > >> >>> voted (as part of >> >> >> > >>> > >> >>> the spec proposal). >> >> >> > >>> > >> >>> >> >> >> > >>> > >> >>> I think it's fair to identify a proposal vote as a >> >> >> > >>> > >> >>> "code modification" vote. >> >> >> > >>> > >> >>> It means that it follows this model: a negative vote >> >> >> > >>> > >> >>> constitutes a >> >> >> > >>> > >> >>> veto , which the voting group (generally the PMC of a >> >> >> > >>> > >> >>> project) cannot >> >> >> > >>> > >> >>> override. Again, this model may be modified by a lazy >> >> >> > >>> > >> >>> consensus >> >> >> > >>> > >> >>> declaration when the request for a vote is raised, but >> >> >> > >>> > >> >>> the full-stop >> >> >> > >>> > >> >>> nature of a negative vote does not change. Under normal >> >> >> > >>> > >> >>> (non-lazy >> >> >> > >>> > >> >>> consensus) conditions, the proposal requires three >> >> >> > >>> > >> >>> positive votes and >> >> >> > >>> > >> >>> no negative votes in order to pass; if it fails to >> >> >> > >>> > >> >>> garner the >> >> >> > >>> > >> >>> requisite amount of support, it doesn't. Then the >> >> >> > >>> > >> >>> proposer either >> >> >> > >>> > >> >>> withdraws the proposal or modifies the code and >> >> >> > >>> > >> >>> resubmits it, or the >> >> >> > >>> > >> >>> proposal simply languishes as an open issue until >> >> >> > >>> > >> >>> someone gets around >> >> >> > >>> > >> >>> to removing it. >> >> >> > >>> > >> >>> >> >> >> > >>> > >> >>> We can link to >> >> >> > >>> > >> >>> https://www.apache.org/foundation/voting.html. >> >> >> > >>> > >> >>> >> >> >> > >>> > >> >>> Regards >> >> >> > >>> > >> >>> JB >> >> >> > >>> > >> >>> >> >> >> > >>> > >> >>> On Tue, Mar 12, 2024 at 2:21 AM Renjie Liu >> >> >> > >>> > >> >>> <liurenjie2...@gmail.com> wrote: >> >> >> > >>> > >> >>> > >> >> >> > >>> > >> >>> > Hi, Daniel: >> >> >> > >>> > >> >>> > >> >> >> > >>> > >> >>> > Thanks for this summary. >> >> >> > >>> > >> >>> > >> >> >> > >>> > >> >>> > I think one thing missing is that do we need a vote >> >> >> > >>> > >> >>> > for the proposal to be accepted or rejected? If >> >> >> > >>> > >> >>> > required, what should the voting process be? >> >> >> > >>> > >> >>> > >> >> >> > >>> > >> >>> > On Tue, Mar 12, 2024 at 9:04 AM Daniel Weeks >> >> >> > >>> > >> >>> > <dwe...@apache.org> wrote: >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> Hey everyone, I synced up with JB about the proposal >> >> >> > >>> > >> >>> >> process and wanted to see if we could make some >> >> >> > >>> > >> >>> >> initial progress. >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> Based on some of the earlier discussions, we want to >> >> >> > >>> > >> >>> >> leverage as much of the informal process as >> >> >> > >>> > >> >>> >> possible, but improve discoverability and a little >> >> >> > >>> > >> >>> >> structure. This probably means using github for >> >> >> > >>> > >> >>> >> tracking, google docs where possible for the early >> >> >> > >>> > >> >>> >> proposal implementation comments, and the dev list >> >> >> > >>> > >> >>> >> for discussion threads, awareness and voting. >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> That said, I propose we adopt the following: >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> 1. A simple issue template for initiating a proposal >> >> >> > >>> > >> >>> >> and applying a 'proposal' label to the issue >> >> >> > >>> > >> >>> >> 2. Use a github search link to document current >> >> >> > >>> > >> >>> >> proposals (based on the 'proposal' label) >> >> >> > >>> > >> >>> >> 3. Continue using google docs for proposals >> >> >> > >>> > >> >>> >> documentation/comments (referenced from the github >> >> >> > >>> > >> >>> >> issue) >> >> >> > >>> > >> >>> >> 4. Continue to create DISCUSS threads on the dev >> >> >> > >>> > >> >>> >> list for communication >> >> >> > >>> > >> >>> >> 4. Backfill current proposals by creating issues for >> >> >> > >>> > >> >>> >> them >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> I've created this PR to capture the initial template >> >> >> > >>> > >> >>> >> and docs. >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> I think we want to introduce this with as little >> >> >> > >>> > >> >>> >> overhead as possible. Please follow up with >> >> >> > >>> > >> >>> >> questions/comments so we can close this out. >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> Thanks, >> >> >> > >>> > >> >>> >> Dan >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> >> >> >> > >>> > >> >>> >> On Sun, Mar 10, 2024 at 11:30 PM Jean-Baptiste >> >> >> > >>> > >> >>> >> Onofré <j...@nanthrax.net> wrote: >> >> >> > >>> > >> >>> >>> >> >> >> > >>> > >> >>> >>> Hi Manu >> >> >> > >>> > >> >>> >>> >> >> >> > >>> > >> >>> >>> Yup, it's on my TODO. Thanks for the reminder, I >> >> >> > >>> > >> >>> >>> will be back on this >> >> >> > >>> > >> >>> >>> one this week :) >> >> >> > >>> > >> >>> >>> >> >> >> > >>> > >> >>> >>> Regards >> >> >> > >>> > >> >>> >>> JB >> >> >> > >>> > >> >>> >>> >> >> >> > >>> > >> >>> >>> On Mon, Mar 11, 2024 at 4:07 AM Manu Zhang >> >> >> > >>> > >> >>> >>> <owenzhang1...@gmail.com> wrote: >> >> >> > >>> > >> >>> >>> > >> >> >> > >>> > >> >>> >>> > Hi JB, >> >> >> > >>> > >> >>> >>> > >> >> >> > >>> > >> >>> >>> > Are you still working on this nice proposal? >> >> >> > >>> > >> >>> >>> > >> >> >> > >>> > >> >>> >>> > Regards, >> >> >> > >>> > >> >>> >>> > Manu >> >> >> > >>> > >> >>> >>> > >> >> >> > >>> > >> >>> >>> > On Thu, Jan 4, 2024 at 3:35 PM Fokko Driesprong >> >> >> > >>> > >> >>> >>> > <fo...@apache.org> wrote: >> >> >> > >>> > >> >>> >>> >> >> >> >> > >>> > >> >>> >>> >> Nice! I fully agree with the abovementioned. I >> >> >> > >>> > >> >>> >>> >> originally set up the stalebot for the issues >> >> >> > >>> > >> >>> >>> >> because I noticed that there were many issues >> >> >> > >>> > >> >>> >>> >> around old Spark versions that weren't even >> >> >> > >>> > >> >>> >>> >> maintained anymore. I feel it is better to >> >> >> > >>> > >> >>> >>> >> either close or take action on an issue. For me, >> >> >> > >>> > >> >>> >>> >> it makes sense to extend this to PRs as well. >> >> >> > >>> > >> >>> >>> >> >> >> >> > >>> > >> >>> >>> >> Same as Amogh said, always feel free to ping me >> >> >> > >>> > >> >>> >>> >> when either a PR or issue lingering and you need >> >> >> > >>> > >> >>> >>> >> some eyes on it. >> >> >> > >>> > >> >>> >>> >> >> >> >> > >>> > >> >>> >>> >> Kind regards, >> >> >> > >>> > >> >>> >>> >> Fokko >> >> >> > >>> > >> >>> >>> >> >> >> >> > >>> > >> >>> >>> >> Op do 4 jan 2024 om 07:42 schreef Jean-Baptiste >> >> >> > >>> > >> >>> >>> >> Onofré <j...@nanthrax.net>: >> >> >> > >>> > >> >>> >>> >>> >> >> >> > >>> > >> >>> >>> >>> Hi >> >> >> > >>> > >> >>> >>> >>> >> >> >> > >>> > >> >>> >>> >>> That's also the purpose of the reviewers file: >> >> >> > >>> > >> >>> >>> >>> having multiple >> >> >> > >>> > >> >>> >>> >>> reviewers per tag. >> >> >> > >>> > >> >>> >>> >>> >> >> >> > >>> > >> >>> >>> >>> Thanks guys for your feedback, I will move >> >> >> > >>> > >> >>> >>> >>> forward with the PR :) >> >> >> > >>> > >> >>> >>> >>> >> >> >> > >>> > >> >>> >>> >>> Regards >> >> >> > >>> > >> >>> >>> >>> JB >> >> >> > >>> > >> >>> >>> >>> >> >> >> > >>> > >> >>> >>> >>> On Thu, Jan 4, 2024 at 6:38 AM Ajantha Bhat >> >> >> > >>> > >> >>> >>> >>> <ajanthab...@gmail.com> wrote: >> >> >> > >>> > >> >>> >>> >>> > >> >> >> > >>> > >> >>> >>> >>> > +1, >> >> >> > >>> > >> >>> >>> >>> > >> >> >> > >>> > >> >>> >>> >>> > Some of my PRs have been open for a long time >> >> >> > >>> > >> >>> >>> >>> > and sometimes it doesn't get the attention it >> >> >> > >>> > >> >>> >>> >>> > requires. >> >> >> > >>> > >> >>> >>> >>> > Notifying both the reviewer and the author >> >> >> > >>> > >> >>> >>> >>> > can help expedite the review process and >> >> >> > >>> > >> >>> >>> >>> > facilitate quicker handling of new >> >> >> > >>> > >> >>> >>> >>> > contributions. >> >> >> > >>> > >> >>> >>> >>> > I think having more than one committer >> >> >> > >>> > >> >>> >>> >>> > assigned for PR can also definitely help in >> >> >> > >>> > >> >>> >>> >>> > speeding up the process if one of the >> >> >> > >>> > >> >>> >>> >>> > committer is busy or on holiday. >> >> >> > >>> > >> >>> >>> >>> > >> >> >> > >>> > >> >>> >>> >>> > But we also need to think on the next steps. >> >> >> > >>> > >> >>> >>> >>> > What if we still don't receive the necessary >> >> >> > >>> > >> >>> >>> >>> > response even after sending notifications? >> >> >> > >>> > >> >>> >>> >>> > Should we have a slack channel for those PRs >> >> >> > >>> > >> >>> >>> >>> > to conclude by discussing (or some guidelines >> >> >> > >>> > >> >>> >>> >>> > on how to take it further). >> >> >> > >>> > >> >>> >>> >>> > >> >> >> > >>> > >> >>> >>> >>> > We can have a trial run for some days and see >> >> >> > >>> > >> >>> >>> >>> > how it goes. >> >> >> > >>> > >> >>> >>> >>> > >> >> >> > >>> > >> >>> >>> >>> > Thanks, >> >> >> > >>> > >> >>> >>> >>> > Ajantha >> >> >> > >>> > >> >>> >>> >>> > >> >> >> > >>> > >> >>> >>> >>> > On Thu, Jan 4, 2024 at 8:19 AM Amogh >> >> >> > >>> > >> >>> >>> >>> > Jahagirdar <am...@tabular.io> wrote: >> >> >> > >>> > >> >>> >>> >>> >> >> >> >> > >>> > >> >>> >>> >>> >> +1, I think this is a step in the right >> >> >> > >>> > >> >>> >>> >>> >> direction. One other consideration I wanted >> >> >> > >>> > >> >>> >>> >>> >> to bring up was dependabot and if there's >> >> >> > >>> > >> >>> >>> >>> >> any unique handling we want to do there >> >> >> > >>> > >> >>> >>> >>> >> because I've noticed that PRs from >> >> >> > >>> > >> >>> >>> >>> >> dependabot tend to pile up. I think with the >> >> >> > >>> > >> >>> >>> >>> >> proposal we won't really need to do anything >> >> >> > >>> > >> >>> >>> >>> >> unique and just treat it as a normal PR (it >> >> >> > >>> > >> >>> >>> >>> >> would be a build label with its own set of >> >> >> > >>> > >> >>> >>> >>> >> reviewers) and we'll get notified the same >> >> >> > >>> > >> >>> >>> >>> >> way. >> >> >> > >>> > >> >>> >>> >>> >> >> >> >> > >>> > >> >>> >>> >>> >> I'll also say for reviews (speaking for >> >> >> > >>> > >> >>> >>> >>> >> myself, but I think many others probably >> >> >> > >>> > >> >>> >>> >>> >> feel this way as well), always feel free to >> >> >> > >>> > >> >>> >>> >>> >> ping on Slack and follow up :) But overall I >> >> >> > >>> > >> >>> >>> >>> >> do like having more of a mechanism. >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > -- >> >> >> > > Ryan Blue >> >> >> > > Tabular
