Hi all,

In the past discussion of Supporting Chinese Documentation for Apache
Flink[1], we reach a consensus to add a documentation check item to the
flinkbot review process.

I propose the idea here to get some more feedbacks about this.

The new item we want to add is:

```
### 6. Are English and Chinese documentation updated?

If the pull request introduces a new feature, the feature should be
documented. The Flink community is maintaining both English and Chinese
documents. So both English and Chinese documentation should be updated. If
you are not familiar with Chinese language, please open a JIRA tagged with
the `chinese-translation` component for Chinese documentation translation
and link it with current JIRA issue. If you are familiar with Chinese
language, you are encouraged to update both sides in one pull request.
```

We have opened a pull request [2] to update it to the website.

What do you think about this?

Thanks,
Jark


[1]
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Contributing-Chinese-website-and-docs-to-Apache-Flink-tt26603.html#a26890
[2] https://github.com/apache/flink-web/pull/190

On Thu, 7 Mar 2019 at 21:48, Robert Metzger <rmetz...@apache.org> wrote:

> Each Jira ticket has a "last updated" field, and in a JIRA search, you can
> sort results by that field.
>
> So I will regularly check all Jira tickets which have been updated since
> the last time my tool checked. For all changed Jira tickets, I'll update
> the PR if the component has changed.
>
> The implementation will be a bit differently, to not run into rate limits
> with the JIRA or GitHub API.
>
> On Thu, Mar 7, 2019 at 2:40 PM Chesnay Schepler <ches...@apache.org>
> wrote:
>
> > How do you intend to keep the label up-to-date with whatever
> > modifications are made in JIRA?
> >
> > On 07.03.2019 13:40, Robert Metzger wrote:
> > > I will automatically assign the Jira component as a label to the PR,
> yes.
> > > You won't have to manually update the label on the PR, this will be
> done
> > > automatically.
> > >
> > > So JIRA will stay the ground truth for setting the component correctly.
> > >
> > > On Thu, Mar 7, 2019 at 10:11 AM Chesnay Schepler <ches...@apache.org>
> > wrote:
> > >
> > >> Component labels seem a bit redundant. Every JIRA with an open PR
> > >> already has a "pull-request-available" tag.
> > >> So this information already exists.
> > >>
> > >> I assume you'll base the labels on the component tags at the time the
> PR
> > >> is opened, but this also implies that they may be set incorrectly (or
> > >> not at all) by the contributor. In this case we now have to update the
> > >> component both in JIRA and on GitHub, and I'm most certainly not
> looking
> > >> forward to that.
> > >>
> > >> On 06.03.2019 13:51, Robert Metzger wrote:
> > >>> This is the picture:
> > >>>
> > >>
> >
> https://user-images.githubusercontent.com/89049/53882383-7fda9380-4016-11e9-877d-10cdc00bdfbd.png
> > >>> Speaking about feature requests, priorities and time-spend: My plan
> was
> > >> to
> > >>> now work on introducing a new label category for the components.
> > >>> This should get us a lot better overview over the per-component
> > >>> status/health of pull requests.
> > >>>
> > >>>
> > >>> On Wed, Mar 6, 2019 at 12:58 PM Chesnay Schepler <ches...@apache.org
> >
> > >> wrote:
> > >>>> The image didn't go through.
> > >>>>
> > >>>> I would keep it as is; imo there are significantly more important
> > things
> > >>>> that I'd like Robert to spend time on. (literally everything in the
> > >>>> Feature requests section)
> > >>>>
> > >>>> If we want to better distinguish new PRs I would suggest to either
> a)
> > >>>> introduce a dedicated "New" label or b) not attach any label by
> > default,
> > >>>> and only attach the description label if someone has
> > >>>> approved/disapproved it.
> > >>>>
> > >>>> On 06.03.2019 12:37, Robert Metzger wrote:
> > >>>>> Hey Kurt,
> > >>>>> thanks a lot for this idea.
> > >>>>>
> > >>>>> My reasoning behind using just one color is the following: I wanted
> > to
> > >>>>> use one color per category of labels.
> > >>>>> So when we are introducing labels for components, that it'll look
> > like
> > >>>>> this:
> > >>>>>
> > >>>>> image.png
> > >>>>>
> > >>>>> But we could of course also go with color families per category. So
> > >>>>> "review" is green colors, "component" is red colors and so on.
> > >>>>>
> > >>>>> If nobody objects (or agrees) with me, I'll change the colors soon.
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Mar 6, 2019 at 7:51 AM Kurt Young <ykt...@gmail.com
> > >>>>> <mailto:ykt...@gmail.com>> wrote:
> > >>>>>
> > >>>>>       Hi Dev,
> > >>>>>
> > >>>>>       I've been using the flinkbot and the label for a couple days,
> > it
> > >>>>>       worked
> > >>>>>       really well! I have a minor suggestion, can we
> > >>>>>       use different colors for different labels? We don't need to
> > have
> > >>>>>       different
> > >>>>>       colors for every label, but only to distinguish whether
> > >>>>>       someone had review the PR.
> > >>>>>       For example, "review=description?" is the initial default
> > label,
> > >>>>>       and it may
> > >>>>>       indicate that no reviewer has been try to review it.
> > >>>>>
> > >>>>>       For "review=architecture?", "review=consensus?",
> > >>>>>       "review=quality?", they
> > >>>>>       indicate that at least someone has try to review it and
> > >>>>>       approved something. It sounds like the review is in progress.
> > >>>>>
> > >>>>>       For "review=approved ✅", it indicates the review is finished.
> > >>>>>
> > >>>>>       So i think 3 colors is enough, it tell committers whether the
> > >>>>>       review has
> > >>>>>       not started yes, or in progress, or is finished.
> > >>>>>
> > >>>>>       What do you think?
> > >>>>>
> > >>>>>       Best,
> > >>>>>       Kurt
> > >>>>>
> > >>>>>
> > >>>>>       On Mon, Mar 4, 2019 at 6:50 PM Robert Metzger <
> > >> rmetz...@apache.org
> > >>>>>       <mailto:rmetz...@apache.org>> wrote:
> > >>>>>
> > >>>>>       > GitHub has two methods for authentication with the APIs:
> > >>>>>       > a) using an account's oauth token
> > >>>>>       > b) using the GitHub Apps API
> > >>>>>       >
> > >>>>>       > Most of the libraries for the GH API use a), so does
> > Flinkbot.
> > >>>>>       The problem
> > >>>>>       > with a) is that it does not allow for fine-grained access
> > >>>>>       control, and
> > >>>>>       > Infra does not want to give Flinkbot "write" access to
> > >>>>>       "apache/flink".
> > >>>>>       > That's why I need to rewrite parts of the bot to support
> b),
> > >>>>>       which allows
> > >>>>>       > to give access only a repo's metadata, but not the code
> > itself.
> > >>>>>       >
> > >>>>>       >
> > >>>>>       >
> > >>>>>       >
> > >>>>>       > On Sat, Mar 2, 2019 at 12:42 AM Thomas Weise <
> t...@apache.org
> > >>>>>       <mailto:t...@apache.org>> wrote:
> > >>>>>       >
> > >>>>>       > > It would be good to encourage participation of
> > non-committers
> > >>>>>       in the
> > >>>>>       > review
> > >>>>>       > > process, so +1 for allowing everyone to operate the bot.
> > >>>>>       > >
> > >>>>>       > > Github approval will show a green checkmark for committer
> > >>>> approval
> > >>>>>       > > (assuming accounts were linked via gitbox) - that should
> > >> provide
> > >>>>>       > sufficient
> > >>>>>       > > orientation?
> > >>>>>       > >
> > >>>>>       > > I just noticed that flinkbot seems to act as Robert when
> it
> > >>>>>       comes to
> > >>>>>       > label
> > >>>>>       > > management? I think that is confusing (besides earning
> > Robert
> > >>>>>       a lot of
> > >>>>>       > > extra github notification mail thanks to participation on
> > >>>>>       every PR :)
> > >>>>>       > >
> > >>>>>       > > Overall flinkbot is very useful, thanks for all the work
> on
> > >>>>>       it! I heard
> > >>>>>       > > positive feedback from other contributors, I think they
> see
> > >> their
> > >>>>>       > > contributions are better received now.
> > >>>>>       > >
> > >>>>>       > > Thomas
> > >>>>>       > >
> > >>>>>       > >
> > >>>>>       > >
> > >>>>>       > > On Fri, Mar 1, 2019 at 8:38 AM Robert Metzger
> > >>>>>       <rmetz...@apache.org <mailto:rmetz...@apache.org>>
> > >>>>>       > wrote:
> > >>>>>       > >
> > >>>>>       > > > I will update labels only based on committer's
> approvals
> > >> (for
> > >>>>>       > > everything),
> > >>>>>       > > > I think that's cleaner.
> > >>>>>       > > >
> > >>>>>       > > > We can always revisit this.
> > >>>>>       > > >
> > >>>>>       > > > On Wed, Feb 27, 2019 at 4:31 PM Chesnay Schepler
> > >>>>>       <ches...@apache.org <mailto:ches...@apache.org>>
> > >>>>>       > > > wrote:
> > >>>>>       > > >
> > >>>>>       > > > > Fore code-quality/description I agree, but consensus
> > and
> > >>>>>       the final
> > >>>>>       > > > > approval should require a committer IMO.
> > >>>>>       > > > >
> > >>>>>       > > > > On 27.02.2019 15:08, Robert Metzger wrote:
> > >>>>>       > > > >
> > >>>>>       > > > > I did not put any restrictions on who can communicate
> > with
> > >>>>>       the bot!
> > >>>>>       > > > > But since there is currently no way of overriding
> > >>>>>       somebody's approval
> > >>>>>       > > for
> > >>>>>       > > > > something, this can easily lead to such a situation.
> > >>>>>       > > > >
> > >>>>>       > > > > My thinking was that a committer still needs to
> > manually
> > >>>>>       check who
> > >>>>>       > > > > approved a pull request, and I wanted to be open for
> > >>>>>       non-committers
> > >>>>>       > to
> > >>>>>       > > > > participate in the review process.
> > >>>>>       > > > > WIth the labels in place, this can easily send the
> > wrong
> > >>>>>       message.
> > >>>>>       > > > >
> > >>>>>       > > > > What should we do?
> > >>>>>       > > > > A) we restrict sending commands to the bot to
> > committers?
> > >>>>>       > > > > B) only approvals from committers matter for applying
> > >> labels?
> > >>>>>       > > > > C) we allow committers to override approvals
> > >>>>>       > > > >
> > >>>>>       > > > > I'm leaning towards B, as it encourages
> non-committers
> > to
> > >>>>>       > participate.
> > >>>>>       > > > >
> > >>>>>       > > > >
> > >>>>>       > > > > On Wed, Feb 27, 2019 at 2:01 PM Chesnay Schepler
> > >>>>>       <ches...@apache.org <mailto:ches...@apache.org>
> > >>>>>       > >
> > >>>>>       > > > > wrote:
> > >>>>>       > > > >
> > >>>>>       > > > >> Just noticed that _anyone_ can approve a PR now, see
> > >>>>>       > > > >> https://github.com/apache/flink/pull/7801.
> > >>>>>       > > > >>
> > >>>>>       > > > >> Not sure about the solution, but as it stands it is
> > >>>>>       rather trivial
> > >>>>>       > to
> > >>>>>       > > > >> nuke the review process of the entire project.
> > >>>>>       > > > >>
> > >>>>>       > > > >> On 13.02.2019 10:29, Robert Metzger wrote:
> > >>>>>       > > > >> > Hey all,
> > >>>>>       > > > >> >
> > >>>>>       > > > >> > the flinkbot has been active for a week now, and I
> > hope
> > >>>> the
> > >>>>>       > initial
> > >>>>>       > > > >> hiccups
> > >>>>>       > > > >> > have been resolved :)
> > >>>>>       > > > >> >
> > >>>>>       > > > >> > I wanted to start this as a permanent thread to
> > discuss
> > >>>>>       problems
> > >>>>>       > and
> > >>>>>       > > > >> > improvements with the bot.
> > >>>>>       > > > >> >
> > >>>>>       > > > >> > *So please post here if you have questions,
> > problems or
> > >>>>>       ideas how
> > >>>>>       > to
> > >>>>>       > > > >> > improve it!*
> > >>>>>       > > > >> >
> > >>>>>       > > > >>
> > >>>>>       > > > >>
> > >>>>>       > > > >
> > >>>>>       > > >
> > >>>>>       > >
> > >>>>>       >
> > >>>>>
> > >>
> >
> >
>

Reply via email to