osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 581: Using GitHub Issues for CPython


On Fri, Mar 8, 2019 at 12:41 AM Mariatta <mariatta at python.org> wrote:

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues
> for CPython
>
> Full text: https://www.python.org/dev/peps/pep-0581/
>
>
Thanks a lot for doing this!

* The current bug tracker has low contributions and moving to a place like
GitHub would open up to a lot of opportunities like integrations, webhooks
where people can build custom workflow etc. along with reducing the
maintenance burden on the team.
* GitHub also allows markdown and syntax highlighting on code snippets
would be much easier to read compared to current tracker. In some cases
GitHub can even inline the code for a permalink to a single line which adds
more context. Also support for editing comments to fix minor typos links
are great. Emoji support :)
* The current bpo search is surprisingly very effective though it just does
substring search across comments and patches I believe. If not I can google
keywords with site:bugs.python.org to get relevant results. I expect search
to be better on GitHub but worth experimenting since searching to get
related issues/discussion helps a lot in triaging.

Some points worth considering and some of them are addressed in the PEP
already.

* Moving to GitHub also comes at a cost of accessibility where there might
be people posting questions that are more suitable for stackoverflow,
python-list etc. Thus there might be more incoming issues that would
require more effort on triaging.
* There could be explicit guidelines on when a triager should close an
issue and current bpo supports custom fields for resolution, state of the
issue (open/close/pending/needs-test/patch-review)  that are updated.
Besides closing the issue there could be labels or a comment format to
describe the rationale and resolution.
* There could also be guidelines on when to lock the thread since there
could be cases where security issues or issues that can trigger heated
arguments are posted. It could get even more attention when it's posted on
Reddit or hackernews attracting unwanted attention e.g. security issues in
npm posted to reddit. Someone can chime in to lock it but guidelines on
when to do this would be helpful so that decision is not based on personal
opinion to lock it.
* Extended discussions in some cases along with no proper support for
threading could result in lot of duplicated messages that would be hard to
scroll through. It's a problem with current tracker too but something that
can come up where people will use +1 comments instead of using thumbs up
emoji. Rust community had some similar concerns since they do RFC
discussions on GitHub that result in 200+ comments. Though we don't do PEP
discussions some bugs can result in this.
* I wish python-bug-list, weekly summary continues to be integrated with
GitHub too since some of us don't want to watch the repo to get all the
activity along with pull requests and just want to track activity on issues.
* Currently there is some link rot on bpo for svn related links, broken
patch file links etc. Moving to GitHub I guess they are handled like magic
links for PEPs, bpo-NNNN, etc. that are mentioned in the PEP 581.

Personally, I think more people will love it once they get to use it so if
something like 100 issues can be migrated to a sample repo with labels,
content etc. As a shameless plug I tried migrating around 150 issues in
current bpo to GitLab sometime back with components as labels. Though an
apple to oranges comparison (GitLab UI vs GitHub UI) I personally find the
UI (also GitHub UI) very easy to navigate in terms of clicking on labels,
search, sort, filter etc. in https://gitlab.com/tirkarthi/python-bugs/issues
and the issue is more easy to read with markdown support for code where I
added highlight to snippet
https://gitlab.com/tirkarthi/python-bugs/issues/140

-- 
Regards,
Karthikeyan S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190308/88e103cb/attachment-0001.html>