[core-workflow] We will be moving to GitHub

[Nicholas Chammas]

First-timer here on this list. Just wanted to chime in briefly on a few
things.

Basically a way to map an issue to a PR (or vice-versa). Probably the
simplest solution is to allow pasting in a GitHub PR URL or the PR # to
make the association. The other option is for the bot to accept a command
to make the association. No reason we can’t have both, though. But either
way we should have a way to connect PRs to issues.

I have seen many projects — specifically those using an issue tracker
outside of GitHub — accomplish this by asking their contributors to include
the issue number in the title.

Two example projects doing this: Apache Spark
<https://github.com/apache/spark/pulls>, Scala
<https://github.com/scala/scala/pulls>

Then, those projects would have some kind of bot or hook (like Berker
mentioned) use the issue number in the PR title to create a reference over
on the issue tracker.

For example, here is the script
<https://github.com/apache/spark/blob/master/dev/github_jira_sync.py> that
the Apache Spark project uses to create links on JIRA (their issue tracker)
to PRs. And here is an issue
<https://issues.apache.org/jira/browse/SPARK-11744> where you can see the
link that was automatically created to the PR referencing it (under “Issue
Links”).

If we end up using a CI service with good GitHub integration like Travis,
we may even be able to use it to create the issue links as part of the
build—no bot or separate service required. Additionally, if we want all PRs
to include an issue reference, for example, that could be automatically
enforced. Any PR without an issue reference in the title would fail that
check, which shows up as a nice, clear X on the PR, with a link to more
detail.

I’ll echo what others have said and say that I too am interested in
contributing to Python project infrastructure, especially in the area of CI
integration and various types of automation that make the lives of
contributors and committers easier. I spent a lot of time doing very
similar work for the Apache Spark project. I think it’s an important thing
to work on; lower friction enables more people to contribute more often,
and that’s very important for the long-term health of the project.

Nick
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160103/1f2d7d94/attachment-0001.html>