Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add (optional) reviewer in addition to comment #499

Open
maxandersen opened this issue Nov 21, 2024 · 2 comments
Open

add (optional) reviewer in addition to comment #499

maxandersen opened this issue Nov 21, 2024 · 2 comments

Comments

@maxandersen
Copy link
Member

could we add "add as reviewer" on issues in addition to comment?

usecase is that comments you need to catch "as they come on" and is done for docs on quarkusio/quarkus#44597;
However, if users are added as reviewers, they can query and find them explicitly.

that could be used for code prs in general too, but specific ask is from idea from docs (cc @MichalMaler )
to catch issues sooner.

@MichalMaler
Copy link

MichalMaler commented Nov 21, 2024

I will just add our background story for this to have a whole picture :)

This PR, quarkusio/quarkus#44597 , enhances our notification system for situations where upstream updates are made to docs that are marked for downstreaming. While email notifications are helpful, we need more than email notifications for our team to act quickly and efficiently.

To address this, I propose that myself, Sheila, and Rolfe be automatically added as Reviewers or Assignees for such PRs, alongside any Subject Matter Expert (SME) responsible for the respective document. This would allow us to receive notifications directly in our IDEs, such as VS Code or IntelliJ, through their GitHub plugins. With this setup, we can see where our attention is required and provide timely reviews directly in Quarkus as soon as the PR is opened rather than during pre-release QE reviews.

Our reviews would focus solely on grammar and style and would not act as blockers. The goal is to ensure that we react promptly to contributions and improve documentation quality at the earliest stage while preserving the contributor's original intent.
Email notifications can continue to serve as a fallback mechanism for those who do not use IDEs or prefer not to configure them. This way, any time a new PR touches a file from our watchlist, we can intervene, explain the purpose of our review, and clarify that we intend to enhance the text without altering its meaning.

A key advantage of integrating these notifications into IDEs is the ability to branch into the PR with a single click and, if necessary, directly commit updates after reaching an agreement with the PR author. This streamlined workflow would help us provide value-added reviews efficiently.

We used a similar approach in Eclipse Che, which proved effective.
CC: @sheilamjones @rolfedh @sangeetaraghu

@MichalMaler
Copy link

MichalMaler commented Nov 25, 2024

Currently, we have two docs labels in GitHub.

  1. area/documentation -> This label creates an email notification by using a Quarkus bot tag in a PR.
  • Possible Use-cases:
    ** Label is added automatically by changing the docs folder -> writers are notified about everything that happens in that folder.
    ** Label is added manually -> Writers are notified when their opinion or attention is needed.
    The question is, which one of these two options is more useful?
  1. area/docstyle -> This label needs to be added automatically when any of the files from the watchlist are edited. As a result, members of the Quarkus docs team are automatically added as Reviewers to jump in quickly and provide a review.
    Also, thanks to this label, we can track down all the PRs that were updating the files from the watchlist if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants