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 >>> >>>>>>>>>>>> >>> >>
