There are also some "dashboards" (mostly just saved filters, in list view)
here: https://cwiki.apache.org/confluence/display/ARROW/Dashboards
They're not great either, but at least they can give us some common views
to pay attention to.
Neal
On Fri, May 31, 2019 at 5:56 AM Wes McKinney wrote:
On Fri, May 31, 2019 at 3:21 AM Antoine Pitrou wrote:
>
>
> Le 31/05/2019 à 10:04, Fan Liya a écrit :
> > @Antoine Pitrou, you mean the titles of JIRA/PR should be chosen carefully?
>
> That helps a bit for visual filtering, but visual filtering quickly
> becomes inefficient if there are too many
Le 31/05/2019 à 10:04, Fan Liya a écrit :
> @Antoine Pitrou, you mean the titles of JIRA/PR should be chosen carefully?
That helps a bit for visual filtering, but visual filtering quickly
becomes inefficient if there are too many issues.
No, I mean having views that only display certain kinds o
@Antoine Pitrou, you mean the titles of JIRA/PR should be chosen carefully?
Best,
Liya Fan
On Fri, May 31, 2019 at 12:03 AM Antoine Pitrou wrote:
>
> One of the aspects of the problem is that our tools (Github, JIRA) don't
> allow us to work with categories easily.
>
> Regards
>
> Antoine.
>
>
One of the aspects of the problem is that our tools (Github, JIRA) don't
allow us to work with categories easily.
Regards
Antoine.
Le 30/05/2019 à 15:59, Wes McKinney a écrit :
> They're complementary. At least in the short term the spreadsheet can
> help us get our current backlog under cont
They're complementary. At least in the short term the spreadsheet can
help us get our current backlog under control. I'd like to at least be
thinking about tools that can help us when patch volume inevitably
grows to 2-3 times the current level.
On Thu, May 30, 2019 at 12:28 AM Micah Kornfield wr
That sounds great Wes, than you and your team for taking it on.
Can you clarify, if you would prefer this approach to the one I proposed
above (i.e. should I delete the spreadsheet) or are they complementary?
Thanks,
Micah
On Wed, May 29, 2019 at 12:07 PM Wes McKinney wrote:
> On the call toda
On the call today we discussed possibly repurposing the Spark PR
dashboard application for our use
* https://github.com/databricks/spark-pr-dashboard
* https://spark-prs.appspot.com/
This is a project that my team could take on this year sometime
On Wed, May 29, 2019 at 4:12 AM Fan Liya wrote:
Sounds like a great idea. I am interested in Java PRs.
Best,
Liya Fan
On Wed, May 29, 2019 at 1:28 PM Micah Kornfield
wrote:
> Sorry for the delay. I created
>
> https://docs.google.com/spreadsheets/d/146lDg11c5ohgVkrOglrb42a1JB0Gm1qBRbnoDlvB8QY/edit#gid=0
> as
> simple way to distribute old P
Sorry for the delay. I created
https://docs.google.com/spreadsheets/d/146lDg11c5ohgVkrOglrb42a1JB0Gm1qBRbnoDlvB8QY/edit#gid=0
as
simple way to distribute old PRs if you are interested in helping, please
add a comment under the language and I'll add you.
PMC/Committers, I can share edit access if
I agree on hand curation for now.
I'll try to setup a sign up spreadsheet for shepherding old PRs and once
that done assign reviewers/ping old PRs. I expect to have something to
share by the weekend.
On Tuesday, May 21, 2019, Wes McKinney wrote:
> I think maintainers or contributors should be
I think maintainers or contributors should be responsible for closing
PRs, it also helps with backlog curation (sometimes when a stale PR is
closed the JIRA may also be closed if it's a Won't Fix)
On Tue, May 21, 2019 at 1:12 PM Antoine Pitrou wrote:
>
>
>
> Le 21/05/2019 à 20:02, Neal Richardson
Le 21/05/2019 à 20:02, Neal Richardson a écrit :
> Automatically close stale PRs? https://github.com/probot/stale
That doesn't sound like a good idea to me.
Regards
Antoine.
Automatically close stale PRs? https://github.com/probot/stale
On Tue, May 21, 2019 at 11:00 AM Wes McKinney wrote:
> Any other thoughts about process to manage the backlog?
>
> On Thu, May 16, 2019 at 2:58 PM Wes McKinney wrote:
> >
> > hi Micah,
> >
> > This sounds like a reasonable proposal,
Any other thoughts about process to manage the backlog?
On Thu, May 16, 2019 at 2:58 PM Wes McKinney wrote:
>
> hi Micah,
>
> This sounds like a reasonable proposal, and I agree in particular for
> regular contributors that it makes sense to close PRs that are not
> close to being in merge-readin
hi Micah,
This sounds like a reasonable proposal, and I agree in particular for
regular contributors that it makes sense to close PRs that are not
close to being in merge-readiness to thin the noise of the patch queue
We have some short-term issues such as various reviewers being busy
lately (e.g
Our backlog of open PRs is slowly creeping up. This isn't great because it
allows contributions to slip through the cracks (which in turn possibly
turns off new contributors). Perusing PRs I think things roughly fall into
the following categories.
1. PRs are work in progress that never got com
17 matches
Mail list logo
