community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Knowles <k...@apache.org>
Subject Re: Discussions in pull requests vs. dev list (was: The Apache Way and good developers...)
Date Fri, 02 Nov 2018 18:32:53 GMT
This comes up a lot on Beam too. We have a practice where if a PR is a big
change, or if discussion veers into into design details rather than just
code, we expect our committers to say "let's move this to the dev list". We
also try to encourage everyone to announce on dev@ not just for the design
discussion, but also to circle back and close the loop once it is merged.
Otherwise the archive is a bunch of loose ends and you can't tell what was
done.

It takes constant work to maintain this culture. We are not nearly 100%
successful; people are sometimes surprised at what has happened that they
didn't know about. Partly, it is just that there is so much going on (10-20
PRs a day) but I would eagerly follow progress and contribute (ideally,
availability pending) to any ideas for (opt-in) culture or automation work
on this topic.

Kenn

On Fri, Nov 2, 2018 at 11:02 AM Christopher <ctubbsii@apache.org> wrote:

> In Accumulo and Fluo, we route to notifications@ also. If these went
> to dev@, it would be too spammy, and I suspect even fewer people would
> participate on important dev@ threads than they do now. Letting it go
> to notifications@, people can subscribe to all activity there, if they
> wish... or they can go to GitHub and subscribe/unsubscribe to GitHub
> notifications for the entire repo ("Watch"), or per-thread, based on
> their individual desires. They can also unsubscribe from
> notifications@ to avoid duplicate notices if they are already
> subscribed to GitHub's notifications (which, to be honest, are far
> more useful, easier to read, and better formatted, than emails from
> ASF with the same content; you can also automatically avoid notices
> from your own activity... something you can't do on list). Using
> notifications@ instead of dev@ and users choosing (or not) to get
> notifications from GitHub is the best of both worlds and provides
> maximal user choice.
>
> There may be room for suggested improvements and best practices, but I
> think it would be a mistake if ASF were to try to impose a more spammy
> workflow to dev@ onto every PMC, as a requirement. I understand the
> utility and universality of mailing lists... but there comes a point
> where our reliance on them for all activity, becomes a deterrent to
> ASF participation, especially for younger contributors who expect more
> convenience than threaded walls of text in their email inbox.
> On Fri, Nov 2, 2018 at 1:46 PM Joan Touzet <wohali@apache.org> wrote:
> >
> > We also use them successfully on CouchDB and I don't see the problem
> here.
> > We do route these notifications to notifications@, not dev@.
> > My email client properly threads multiple comments on the same PR.
> >
> > Another option is to use the GitHub "watch" functionality on a
> repository, which can provide better formatted emails than the ASF Infra
> solution currently does. They also seem to thread better for some.
> >
> > It's important to note that our process forces PRs for all changes to
> master or any release branch (R-T-C, not C-T-R), and that PRs cannot be
> merged unless our full test suite passes. This is automatically enforced by
> GitHub for us.
> >
> > Automating an email to dev@ with what PRs have opened/merged/closed
> with numerical counts sounds useful, but not mandatory. People that care
> can just use GitHub's "watch" function, then put filters in their mail
> client to highlight the things they care about (for instance, UI changes,
> or changes to a specific file or directory).
> >
> > -Joan
> > ----- Original Message -----
> > From: "Christofer Dutz" <christofer.dutz@c-ware.de>
> > To: dev@community.apache.org
> > Sent: Friday, November 2, 2018 1:30:47 PM
> > Subject: Re: Discussions in pull requests vs. dev list (was: The Apache
> Way and good developers...)
> >
> > Hi,
> >
> > Well in the PLC4X project we are using GitHub pull requests. All
> comments are forwarded to the list and this is fine. You are able to follow
> what's going on without much problems.
> >
> > However when it comes to the PR reviews, things tend to get it of hand.
> Every now and then I open my mail client to find 50 new emails and all of
> these are related to a single PR and each mail being a single comment. This
> is extremely annoying
> >
> > Chris
> >
> > Outlook for Android<https://aka.ms/ghei36> herunterladen
> >
> > From: Dave Fisher <dave2wave@comcast.net>
> > Sent: Friday, November 2, 2018 4:59:43 PM
> > To: dev@community.apache.org
> > Subject: Re: Discussions in pull requests vs. dev list (was: The Apache
> Way and good developers...)
> >
> > HI Bertrand,
> >
> > YES! This is the big issue with GitHub based projects/podlings.
> >
> > > On Nov 2, 2018, at 9:14 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
> > >
> > > Hi,
> > >
> > > I'd like to address this specifically as I think it's a common issue
> > > in many of our projects today.
> > >
> > > On Fri, Nov 2, 2018 at 4:31 PM Craig Russell <apache.clr@gmail.com>
> wrote:
> > >> ...One potential problem is the work flow using the github tools,
> which can have the effect
> > >> of dialog "off-list" between the submitter and the other devs...
> > >
> > > I agree with that - in a project where most of the action happens on
> > > GitHub (*) it can be hard or impossible to follow the action by just
> > > subscribing to the project's dev list.
> > >
> > > I don't think there's anything wrong with discussions happening in
> > > pull requests (PRs), that's the natural way of working in GitHub and
> > > their tools are extremely convenient and efficient.
> > >
> > > However I think we need to stick to the principle that someone who's
> > > just reading the dev list isn't missing out on anything. It is what
> > > puts part-time contributors on an equal footing with people who work
> > > full time on our projects which is IMO a key aspect of the Apache Way.
> > >
> > > So, how do we fix this? Blindly copying all GitHub PR comments to a
> > > mailing list won't work IMO, as the result is not easy nor convenient
> > > to follow. Copying is required for archival purposes (**) but not
> > > practical for us humans IMO so I recommend copying to an "activity" or
> > > "commits" list, distinct from the dev list.
> > >
> > > One thing that I'd like to experiment in a podling (OpenWhisk) where I
> > > see this problem is to send weekly news to the dev list, listing which
> > > PRs are active, which modules are being actively worked on in
> > > multi-module project, etc. so that people know where to look in
> > > addition to the dev list.
> > >
> > > Ideally automated, but additional human comment certainly helps as
> well.
> >
> > Regarding automation of this I think that the answer really lies in what
> can be automated out of GitHub / GitBox.
> >
> > If you have a conversation with Infra about this, please let me know.
> I’d like to include some of other podlings in this experiment:
> > ECharts
> > Doris
> >
> > Also, Dubbo is making a good switchover to using the dev list and is
> currently voting in a number of contributors as committers. It would be
> interesting to see what information they would find relevant.
> >
> > Regards,
> > Dave
> >
> > >
> > > I have mentioned that idea on the podling's dev list a while ago but
> > > didn't get any traction...I might try this myself and will report here
> > > if that happens. In the meantime, I'm interested in having other
> > > opinions on this topic.
> > >
> > > -Bertrand
> > >
> > > (*) which is fine given our https://gitbox.apache.org/ tooling
> > > (**) in case GitHub goes away - remember we are designing this
> > > Foundation for the next 50 years
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > > For additional commands, e-mail: dev-help@community.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
> > Outlook for Android<https://aka.ms/ghei36> herunterladen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> > For additional commands, e-mail: dev-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message