Help needed to triage issues
13 views
Skip to first unread message
Antonin Delpeuch (lists)
Feb 20, 2021, 4:54:58 AM2/20/21
to openref...@googlegroups.com
Hi all,
We have quite a bit of a backlog of issues to triage and this is making
the life of prospective contributors harder. Would anyone be interested
to help in this area?
We could write up some issue triaging guidelines to make the process a
bit clearer. Here is a broad description of my understanding of the
current process.
When people create new issues, they automatically get assigned the "to
be reviewed" tag:
https://github.com/OpenRefine/OpenRefine/issues?q=is%3Aissue+is%3Aopen+label%3A%22to+be+reviewed%22
Ideally, for each of these issues, someone familiar with OpenRefine (not
necessarily a developer!) should read the issue and try to determine if
there is a genuine bug to fix, or if the enhancement request is
legitimate. In those cases, we can remove the "to be reviewed" tag and
leave the issue open. In the others, the issue should be politely closed.
For a bug, we should first check if it is a real unexpected behaviour or
if just comes from a misunderstanding of the intended behaviour of the
tool (which could suggest an improvement to the documentation). Then, if
it sounds like a genuine problem, we need to check if it can be
reproduced independently on the master branch. If the issue does not
give enough details about the bug to reproduce it on master, mark it as
"not reproducible" and ask the reporter for more information. After some
time without any information from the reporter, we can close the issue.
For an enhancement, we need to make a judgment call of whether the
proposed functionality is in the scope of the project. There is no
universal rule for this of course, so just use your own intuition: do
you think this would improve the tool? Would it be consistent with the
spirit of the project? Trust your own opinion - if people disagree, they
can have a discussion on the issue.
Adding the "good first issue" tag is something that requires a bit more
familiarity with the development process. Personally I only add the
"good first issue" tag if I am confident that I could provide a good
pull request for this with at most a few hours of work. Also, solving
the issue should not require any difficult design decision. I would also
avoid tagging highly debated issues with this tag, because we don't want
the reviewing of a pull request to be stalled by heated debates.
If you want to contribute to issue triaging but do not have the GitHub
privileges to do so, we can grant you the required privileges.
Thank you!
Antonin
We have quite a bit of a backlog of issues to triage and this is making
the life of prospective contributors harder. Would anyone be interested
to help in this area?
We could write up some issue triaging guidelines to make the process a
bit clearer. Here is a broad description of my understanding of the
current process.
When people create new issues, they automatically get assigned the "to
be reviewed" tag:
https://github.com/OpenRefine/OpenRefine/issues?q=is%3Aissue+is%3Aopen+label%3A%22to+be+reviewed%22
Ideally, for each of these issues, someone familiar with OpenRefine (not
necessarily a developer!) should read the issue and try to determine if
there is a genuine bug to fix, or if the enhancement request is
legitimate. In those cases, we can remove the "to be reviewed" tag and
leave the issue open. In the others, the issue should be politely closed.
For a bug, we should first check if it is a real unexpected behaviour or
if just comes from a misunderstanding of the intended behaviour of the
tool (which could suggest an improvement to the documentation). Then, if
it sounds like a genuine problem, we need to check if it can be
reproduced independently on the master branch. If the issue does not
give enough details about the bug to reproduce it on master, mark it as
"not reproducible" and ask the reporter for more information. After some
time without any information from the reporter, we can close the issue.
For an enhancement, we need to make a judgment call of whether the
proposed functionality is in the scope of the project. There is no
universal rule for this of course, so just use your own intuition: do
you think this would improve the tool? Would it be consistent with the
spirit of the project? Trust your own opinion - if people disagree, they
can have a discussion on the issue.
Adding the "good first issue" tag is something that requires a bit more
familiarity with the development process. Personally I only add the
"good first issue" tag if I am confident that I could provide a good
pull request for this with at most a few hours of work. Also, solving
the issue should not require any difficult design decision. I would also
avoid tagging highly debated issues with this tag, because we don't want
the reviewing of a pull request to be stalled by heated debates.
If you want to contribute to issue triaging but do not have the GitHub
privileges to do so, we can grant you the required privileges.
Thank you!
Antonin
Tom Morris
Nov 24, 2022, 9:51:24 PM11/24/22
to openref...@googlegroups.com
This relates to our recent discussion about the "To Be Reviewed" tag. If it hasn't already been done, this email should get split in two and moved to the wiki or web site as:
1. A permanent call to action as a useful way to contribute to OpenRefine as part of the triaging team
2. A set of bug triage guidelines for that team to follow (referenced from #1 so that potential contributors can see what's involved)
Tom
--
You received this message because you are subscribed to the Google Groups "OpenRefine Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine-dev/053c7dd6-7bf9-adff-341c-a65a5980f144%40antonin.delpeuch.eu.
Reply all
Reply to author
Forward
0 new messages