Re: [DISCUSS] WIP PRs and contribution transparency
Hi Gregor, currently we don't have access to any bot service as those accesses are restricted to only committers of the repositories now. Maybe one of us can explore the possibility of using our GitHub account to do it, but that's a good to have feature. Regards, Rohit Yadav Software Architect, ShapeBlue https://www.shapeblue.com From: Riepl, Gregor (SWISS TXT) Sent: Tuesday, April 2, 2019 6:33:06 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] WIP PRs and contribution transparency > In order to be more transparent, I would like to propose that we put > something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues > and I have done on some new PRs you can follow. Labels cannot be used > as not every contributor is a committer. Once the PR is ready for > merging, we can remove it. Is it possible to attach bots to PRs, like for Issues? That way, a bot could take care of attaching and removing labels, and access control could be done according to the contributor's role. rohit.ya...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
Re: [DISCUSS] WIP PRs and contribution transparency
> In order to be more transparent, I would like to propose that we put > something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues > and I have done on some new PRs you can follow. Labels cannot be used > as not every contributor is a committer. Once the PR is ready for > merging, we can remove it. Is it possible to attach bots to PRs, like for Issues? That way, a bot could take care of attaching and removing labels, and access control could be done according to the contributor's role.
Re: [DISCUSS] WIP PRs and contribution transparency
Hi Rohit, We see like the same. Our team will do it. LGTM :) Sven __ Sven Vogel Teamlead Platform EWERK RZ GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 11 F +49 341 42649 - 18 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter, Gerhard Hoyer Registergericht: Leipzig HRB 17023 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 29.03.2019 um 07:40 schrieb Rohit Yadav : > > All, > > > I want to explore a way to be more transparent with the community on PRs > especially new features that we're working on (my colleagues and me at > ShapeBlue), however, like every organization, we have our internal processes > around development, testing, review and internal validation before a PR is > good enough to be merged/included in CloudStack. In the past, we've had a few > situations when an upstream PR sent without a WIP in the title/description or > a Work-In-Progress label but it was merged since all the smoketests passed OK > and it has 2 LGTMs from the community members. In all such cases, another PR > was sent top rectify it but that incurred some overhead in time and energy. > > > In order to be more transparent, I would like to propose that we put > something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues and I > have done on some new PRs you can follow. Labels cannot be used as not every > contributor is a committer. Once the PR is ready for merging, we can remove > it. > > > This would allow the community: > > (a) to be aware that the PR is in progress and should not be merged even if > it gets all smoketests pass and have at least 2 LGTMs. > > (b) presents an opportunity for early conversations, engagements. > > (c) avoid duplicate efforts towards features, bugfixes, and blockers and > encourage joining forces towards a common feature/goal! > > > I think it would be great if more people can join us in this direction. > > Thoughts, concerns? Thanks. > > > Regards, > > Rohit Yadav > > Software Architect, ShapeBlue > > https://www.shapeblue.com > > rohit.ya...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > >
[DISCUSS] WIP PRs and contribution transparency
All, I want to explore a way to be more transparent with the community on PRs especially new features that we're working on (my colleagues and me at ShapeBlue), however, like every organization, we have our internal processes around development, testing, review and internal validation before a PR is good enough to be merged/included in CloudStack. In the past, we've had a few situations when an upstream PR sent without a WIP in the title/description or a Work-In-Progress label but it was merged since all the smoketests passed OK and it has 2 LGTMs from the community members. In all such cases, another PR was sent top rectify it but that incurred some overhead in time and energy. In order to be more transparent, I would like to propose that we put something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues and I have done on some new PRs you can follow. Labels cannot be used as not every contributor is a committer. Once the PR is ready for merging, we can remove it. This would allow the community: (a) to be aware that the PR is in progress and should not be merged even if it gets all smoketests pass and have at least 2 LGTMs. (b) presents an opportunity for early conversations, engagements. (c) avoid duplicate efforts towards features, bugfixes, and blockers and encourage joining forces towards a common feature/goal! I think it would be great if more people can join us in this direction. Thoughts, concerns? Thanks. Regards, Rohit Yadav Software Architect, ShapeBlue https://www.shapeblue.com rohit.ya...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
