Ok, if it's annoying the description can be removed. It will still match extensions though.
On Sat, Feb 15, 2020, 00:58 Kyle Weaver <[email protected]> wrote: > I suppose that'd be okay. It doesn't look like the descriptions add too > much information. > > On Fri, Feb 14, 2020 at 3:55 PM Ismaël Mejía <[email protected]> wrote: > >> Yes a bit annoying and well in any case it can match other of our labels, >> but the issue is that it is matching the label description, that's the >> reason why i want to remove the description, to reduce the number of >> matches to only our labels. >> I can give it a try if you guys agree. >> >> On Sat, Feb 15, 2020 at 12:43 AM Kyle Weaver <[email protected]> wrote: >> >>> > the label `io` is never the first result >>> >>> Same happens on my Mac. Looks like it's listing everything that has an >>> "i" and "o" in it, and "IO" itself happens to be a bit further down in >>> alphabetical order. >>> >>> Kind of annoying, but more of an issue with their fuzzy finder than our >>> labels themselves. Probably easier to just type "label:io" in the filter >>> text box. >>> >>> On Fri, Feb 14, 2020 at 3:36 PM Ismaël Mejía <[email protected]> wrote: >>> >>>> Agree with Kyle, labels and the nice touch of color grouping help to >>>> understand the info about pull requests page much faster. >>>> Alex I don't know if this is an issue of my machine (Ubuntu 18.04) but >>>> I tried with both Firefox and Chrome >>>> and the label `io` is never the first result, so I need to scroll down >>>> because the label descriptions are matched first. >>>> For an example see the attachment image (hope it works). >>>> [image: Peek 2020-02-15 00-30.gif] >>>> >>>> >>>> >>>> >>>> On Fri, Feb 14, 2020 at 3:40 AM Kyle Weaver <[email protected]> >>>> wrote: >>>> >>>>> I'm really enjoying this feature so far! The "Pull Requests" page for >>>>> Beam is now way more readable. Thanks Alex :) >>>>> >>>>> On Wed, Feb 12, 2020 at 9:18 PM Alex Van Boxel <[email protected]> >>>>> wrote: >>>>> >>>>>> What do you exactly mean with github grep... where is it an issue. I >>>>>> find it useful for searching here: >>>>>> >>>>>> [image: Screen Shot 2020-02-13 at 06.11.33.png] >>>>>> >>>>>> OK, you get some false positives, but then the color coding works. >>>>>> You can't search on a category so this looks like the only alternative. I >>>>>> was even thinking of adding more text in the description as it could help >>>>>> new contributors to identify something they could help with. >>>>>> >>>>>> It's also nice when you hover over the label. >>>>>> >>>>>> So, could you exactly pinpoint where you see a problem? >>>>>> >>>>>> _/ >>>>>> _/ Alex Van Boxel >>>>>> >>>>>> >>>>>> On Wed, Feb 12, 2020 at 10:22 PM Ismaël Mejía <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Alex would you consider removing the descriptions from the labels? >>>>>>> It seems that >>>>>>> github greps not only the text of the label but also the text of the >>>>>>> description >>>>>>> producing false positives, e.g. if I search the label `io` it >>>>>>> resolves not only >>>>>>> all the IOs but also results like `core` because it matches the >>>>>>> description >>>>>>> `core-constructIOn-java` and also `extensIOns` making the point of >>>>>>> having >>>>>>> general categories not really useful. >>>>>>> >>>>>>> On Wed, Feb 12, 2020 at 3:01 PM Ismaël Mejía <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> The prefix is just extra characters makes readibility worse, notice >>>>>>>> that the full category (e.g. ios/runners/etc) will match because we >>>>>>>> have an >>>>>>>> extra tag equivalent to the prefix, so filtering is still possible. >>>>>>>> you rarely >>>>>>>> need to filter for more than one criteria, that's why github does >>>>>>>> not allow it >>>>>>>> (and the reason to have the extra per category labels). >>>>>>>> >>>>>>>> The only issue i can see is a possible name collision in the >>>>>>>> future, but until that >>>>>>>> happens i think this is a reasonable tradeoff. >>>>>>>> >>>>>>>> Excellent idea to unifiy the colors for the categories +1 ! >>>>>>>> >>>>>>>> On Wed, Feb 12, 2020 at 2:33 PM Alex Van Boxel <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ismael, I saw that you removed the prefix. I still want to have >>>>>>>>> some grouping between the subtypes, so I color coded them. >>>>>>>>> >>>>>>>>> I also added all the labels in the file. We now have 62 labels. >>>>>>>>> >>>>>>>>> _/ >>>>>>>>> _/ Alex Van Boxel >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 12, 2020 at 12:03 PM Ismaël Mejía <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Forgot to mention, older PRs will look not classified, up to you >>>>>>>>>> guys if you >>>>>>>>>> want to do manually. All new PRs will be automatically labeled. >>>>>>>>>> >>>>>>>>>> On Wed, Feb 12, 2020 at 12:02 PM Ismaël Mejía <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> For info Alex's PR to suport autolabeler was merged today and >>>>>>>>>>> INFRA enabled the plugin. >>>>>>>>>>> I created an artificial PR to check it was autolabeled correctly. >>>>>>>>>>> It is working perfectly now. >>>>>>>>>>> Thanks Alex ! >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 11, 2020 at 5:23 PM Robert Bradshaw < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> +1 to finding the right balance. >>>>>>>>>>>> >>>>>>>>>>>> I do think per-runner makes sense, rather than a general >>>>>>>>>>>> "runners." >>>>>>>>>>>> IOs might make sense as well. Not sure about all the >>>>>>>>>>>> extensions-* I'd >>>>>>>>>>>> leave those out for now. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Feb 11, 2020 at 5:56 AM Ismaël Mejía <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > > So I propose going simple with a limited set of labels. >>>>>>>>>>>> Later on we can refine. Don't forget that does labels only are >>>>>>>>>>>> useful >>>>>>>>>>>> during the life-cycle of a PR. >>>>>>>>>>>> > >>>>>>>>>>>> > Labels are handy for quick filtering and finding PRs we care >>>>>>>>>>>> about for example >>>>>>>>>>>> > to review. >>>>>>>>>>>> > >>>>>>>>>>>> > I agree with the feeling that we should not go to the >>>>>>>>>>>> extremes, but what is >>>>>>>>>>>> > requested in the PR rarely would produce more than 5 labels >>>>>>>>>>>> per PR. For example >>>>>>>>>>>> > if a PR changes KafkaIO and something in the CI it will >>>>>>>>>>>> produce "java io kafka >>>>>>>>>>>> > infra", a pure change on Flink runer will produce "runners >>>>>>>>>>>> flink" >>>>>>>>>>>> > >>>>>>>>>>>> > 100% d'accord with not to have many labels and keep them >>>>>>>>>>>> short, but the current >>>>>>>>>>>> > classification lacks detail, e.g. few people care about some >>>>>>>>>>>> general categories >>>>>>>>>>>> > "runners" or "io", but maintainers may care about their >>>>>>>>>>>> specific categories like >>>>>>>>>>>> > "spark" or "kafka" so I don't think that this extra level of >>>>>>>>>>>> detail is >>>>>>>>>>>> > inappropriate and in the end it will only add one extra label >>>>>>>>>>>> per matching path. >>>>>>>>>>>> > >>>>>>>>>>>> > Let's give it a try if it is too excesive we can took the >>>>>>>>>>>> opposite path and reduce it. >>>>>>>>>>>> > >>>>>>>>>>>> > Ismaël >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On Tue, Feb 11, 2020 at 1:04 PM Alex Van Boxel < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> I'm wondering if we're not taking it too far with those >>>>>>>>>>>> detailed labels. It's like going from nothing to super details. >>>>>>>>>>>> The simples >>>>>>>>>>>> use-case hasn't proven itself in practice yet. >>>>>>>>>>>> >> >>>>>>>>>>>> >> So I propose going simple with a limited set of labels. >>>>>>>>>>>> Later on we can refine. Don't forget that does labels only are >>>>>>>>>>>> useful >>>>>>>>>>>> during the life-cycle of a PR. >>>>>>>>>>>> >> >>>>>>>>>>>> >> _/ >>>>>>>>>>>> >> _/ Alex Van Boxel >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> On Tue, Feb 11, 2020 at 9:46 AM Ismaël Mejía < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Let some comments too, let's keep the discussion on >>>>>>>>>>>> refinements in the PR. >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> On Tue, Feb 11, 2020 at 9:13 AM jincheng sun < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I left comments on PR, the main suggestion is that we may >>>>>>>>>>>> need a discussion about what kind of labels should be add. I would >>>>>>>>>>>> like to >>>>>>>>>>>> share my thoughts as follows: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> I think we need to add labels according to some rules. For >>>>>>>>>>>> example, the easiest way is to add labels by languages, java / >>>>>>>>>>>> python / go >>>>>>>>>>>> etc. But this kind of help is very limited, so we need to >>>>>>>>>>>> subdivide some >>>>>>>>>>>> labels, such as by components. Currently we have more than 70 >>>>>>>>>>>> components, >>>>>>>>>>>> each component is configured with labels, and it seems cumbersome. >>>>>>>>>>>> So we >>>>>>>>>>>> should have some rules for dividing labels, which can play the >>>>>>>>>>>> role of >>>>>>>>>>>> labels without being too cumbersome. Such as: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> We can add `extensions` or `extensions-ideas and >>>>>>>>>>>> extensions-java` for the following components: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - extensions-ideas >>>>>>>>>>>> >>>> - extensions-java-join-library >>>>>>>>>>>> >>>> - extensions-java-json >>>>>>>>>>>> >>>> - extensions-java-protobuf >>>>>>>>>>>> >>>> - extensions-java-sketching >>>>>>>>>>>> >>>> - extensions-java-sorter >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> And it's better to add a label for each Runner as follows: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> - runner-apex >>>>>>>>>>>> >>>> - runner-core >>>>>>>>>>>> >>>> - runner-dataflow >>>>>>>>>>>> >>>> - runner-direct >>>>>>>>>>>> >>>> - runner-flink >>>>>>>>>>>> >>>> - runner-jstorm >>>>>>>>>>>> >>>> - runner-... >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> So, I think would be great to collect feedbacks from the >>>>>>>>>>>> community on the set of labels needed. >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> What do you think? >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Best, >>>>>>>>>>>> >>>> Jincheng >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> Alex Van Boxel <[email protected]> 于2020年2月11日周二 下午3:11写道： >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> I've opened a PR and a ticket with INFRA. >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> PR: https://github.com/apache/beam/pull/10824 >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> _/ >>>>>>>>>>>> >>>>> _/ Alex Van Boxel >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> >>>>>>>>>>>> >>>>> On Tue, Feb 11, 2020 at 6:57 AM jincheng sun < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> +1. Autolabeler seems really cool and it seems that it's >>>>>>>>>>>> simple to configure and set up. >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Best, >>>>>>>>>>>> >>>>>> Jincheng >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> >>>>>>>>>>>> >>>>>> Udi Meiri <[email protected]> 于2020年2月11日周二 上午2:01写道： >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> Cool! >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> On Mon, Feb 10, 2020 at 9:27 AM Robert Burke < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> +1 to autolabeling >>>>>>>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>> On Mon, Feb 10, 2020, 9:21 AM Luke Cwik < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> Nice >>>>>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>>>>>>> On Mon, Feb 10, 2020 at 2:52 AM Alex Van Boxel < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Ha, cool. I'll have a look at the autolabeler. The >>>>>>>>>>>> infra stuff is not something I've looked at... I'll dive into that. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> _/ >>>>>>>>>>>> >>>>>>>>>> _/ Alex Van Boxel >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> On Mon, Feb 10, 2020 at 11:49 AM Ismaël Mejía < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> +1 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> You don't need to write your own action, there is >>>>>>>>>>>> already one autolabeler action [1]. >>>>>>>>>>>> >>>>>>>>>>> INFRA can easily configure it for Beam (as they did >>>>>>>>>>>> for Avro [2]) if we request it. >>>>>>>>>>>> >>>>>>>>>>> The plugin is quite easy to configure and works >>>>>>>>>>>> like a charm [3]. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> [1] https://github.com/probot/autolabeler >>>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-17367 >>>>>>>>>>>> >>>>>>>>>>> [2] >>>>>>>>>>>> https://github.com/apache/avro/blob/master/.github/autolabeler.yml >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> On Mon, Feb 10, 2020 at 11:20 AM Alexey Romanenko < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Great initiative, thanks Alex! I was thinking to >>>>>>>>>>>> add such labels into PR title but I believe that GitHub labels are >>>>>>>>>>>> better >>>>>>>>>>>> since it can be used easily for filtering, for example. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Maybe it could be useful to add more granulation >>>>>>>>>>>> for labels, like “release”, “runners”, “website”, etc but I’m >>>>>>>>>>>> afraid to >>>>>>>>>>>> make the titles too heavy because of this. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > On 10 Feb 2020, at 08:35, Alex Van Boxel < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> > I've started putting labels on PR's. I've done >>>>>>>>>>>> the first page for now (as I'm afraid putting them on older once >>>>>>>>>>>> could >>>>>>>>>>>> affect the stale bot. I hope this is ok. >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> > For now I'm only focussing on language and I'm >>>>>>>>>>>> going to see if I can write a GitLab action for it. I hope this is >>>>>>>>>>>> useful. >>>>>>>>>>>> Other kind of suggestions for labels, that can be automated, are >>>>>>>>>>>> welcome. >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> > <Screen Shot 2020-02-10 at 08.31.09.png> >>>>>>>>>>>> >>>>>>>>>>>> > _/ >>>>>>>>>>>> >>>>>>>>>>>> > _/ Alex Van Boxel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>
