Re: [Twisted-Python] Migrating Trac Tickets to GitHub issues

[Amber Brown]

> On 1 Oct 2017, at 8:15 am, Adi Roiban  wrote:
> 
> Hi,
> 
> I would like to re-start the conversation about migrating Trac tickets
> to GitHub issues.
> 
> My main reason for doing this is to make it easier for people to
> contribute to Twisted.
> 
> In CONTRIBUTING there is this info
> 
> `GitHub doesn't provide adequate tooling for its community.`
> 
> I don't know what is missing in GitHub and why overall Trac is better
> than GitHub issues.
> 
> I know that GitHub Issues is simple and you can't save reports.
> 
> What are problems are there with GitHub issues, which are blocking the
> migration?
> 
> Please send your thoughts.
> 
> Why you think that GitHub issues might be worst than Trac tickets :) ?

Currently, GitHub Issues don't allow for non-committers to make modifications 
to categories, milestones, edit the original ticket description, or close 
tickets. This kinda sucks, because it makes the pool of triagers smaller, and 
also makes most obvious review queue methods harder (adding a category).

I think Mark Williams or someone has hacked up a bot to sidestep this, but... 
again, contributor effort to get that past the line.

- Amber


signature.asc
Description: Message signed with OpenPGP
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Migrating Trac Tickets to GitHub issues

[Craig Rodrigues]

On Sun, Oct 1, 2017 at 3:30 AM, Amber Brown 
wrote:

>
>
> Currently, GitHub Issues don't allow for non-committers to make
> modifications to categories, milestones, edit the original ticket
> description, or close tickets. This kinda sucks, because it makes the pool
> of triagers smaller, and also makes most obvious review queue methods
> harder (adding a category).
>


Are there enough non-committers to Twisted who are actively doing this
right now, to make this
as big an issue as you are claiming?  My guess is no.
Other projects related to klein and treq are using GitHub to track issues
instead of Trac.
Do those projects have problem with non-committers triaging issues, despite
the inability to
create/modify categories/milestones, etc.?

--
Craig
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Defining the review workflow on top of GitHub PR

[Glyph]

> On Sep 30, 2017, at 3:14 PM, Adi Roiban  wrote:
> 
> I am restarting this discussion
> https://twistedmatrix.com/pipermail/twisted-python/2016-May/030333.html
> 
> I am starting a new thread since I want to keep the focus on the
> review process / workflow / markers, and not on the things required to
> accept a PR or do a review.

I'm a little confused.  What do you mean by "process / workflow / markers" if 
not "the things required to accept a PR or do a review"?

> --
> 
>> Proposing: Just open a pull request.  Any open pull request should be 
>> treated as part of the queue.
> 
> I don't like this. If you are not a comitter, you need to open a PR to
> trigger the tests.
> 
> So you want to first open a PR, then wait for tests to execute, then
> fix and only after that to request the review.
> 
> We can start with setting the title to have "[WIP]" marker, to let
> others know that this is not yet ready... but then when changes are
> required, the reviewer will have to set the WIP marker again.. and if
> the reviewer is not a team member, it will not have rights to edit the
> subject.
> 
> But I hope that we can have a bot which once a "please review" comment
> is left, it will set a label.

Mark Williams already started working on this: 
https://github.com/markrwilliams/txghbot

>> Accepting: A committer pushes the big green button;
> 
> +1 ... but maybe also leave a comment :)

We should have more verbiage around the comment stuff, including the "always 
say thank you twice" rule which I don't think is written down anywhere :-).

>> Reviewing: This is the potentially slightly odd part.  I believe a review 
>> that doesn't result in acceptance should close the PR.  We need to be 
>> careful to always include some text that explains that closing a PR does not 
>> mean that the change is rejected, just that the submitter must re-submit.  
>> Initially this would just mean opening a new PR, but Mark Williams is 
>> working on a bot to re-open pull requests when a submitter posts a "please 
>> review" comment: https://github.com/markrwilliams/txghbot
> 
> Since we will have a bot for "please review", why not use the same bot
> to set a label on "please make changes" ?

Yep!

> I think that closing a PR should mean that the work on that branch is
> rejected :)

I still want to require people to open an issue first so we can separate 
closing PRs ("this patch is too bad to be accepted, please try again") from 
closing tickets or issues ("we do not want to do this work").

>> Responding: A submitter can open a new PR, or, once we start running 
>> txghbot, reopen their closed PR.
> 
> As commented above, I am +1 for leaving a "please review" comment and
> having a bot updating the labels.
> 
>> Viewing: 
>> https://github.com/twisted/twisted/pulls?utf8=✓&q=is%3Apr+is%3Aopen+-status%3Afailed
> 
> One we get the "please-review" and "changes-needed" labels it should
> be eaiser to view the queue.

I can update https://twisted.reviews/  (at some 
point) when to point at the appropriate link.  (You've all got it bookmarked, 
right?)

> ---
> 
> Whem multiple reviewers are required, you can use the dedicated GitHub
> Review message and approve it without hiting the merge button.
> 
> -
> 
> I have no idea how other projects are managing the review queue.

"Poorly" :-).

A failure mode of many open source projects is that they have terrible latency 
when responding to new contributors.

> Please send your feedback.
> 
> If we agree on a process based on managing the labes, I can work on
> implemeting the required logic with a bot and GitHub hooks.

Please do coordinate with Mark on this, if you weren't already ;-).

> 
> 
> We can also start by using the WIP marker
> 
> * while preparing the PR
> * once changes are required and the author works on addressing the
> changes requsted on review
> 
> Any PR which is open and does not have the WIP marker means that is
> part of the queue.
> 
> --
> 
> 
> Thanks!
> 
> PS: I have checked pyca/crypography but I don't see any pattern there
> and a lot of PR are merged without any comment
> https://github.com/pyca/cryptography/pulls?q=is%3Apr+is%3Aclosed 
> 

Cryptography is kind of a weird project with a somewhat rarified contributor 
audience, I don't know if it makes sense to copy their process.

-g___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Migrating Trac Tickets to GitHub issues

[Glyph]

> On Oct 1, 2017, at 9:31 AM, Craig Rodrigues  wrote:
> 
> 
> 
> On Sun, Oct 1, 2017 at 3:30 AM, Amber Brown  > wrote:
> 
> 
> Currently, GitHub Issues don't allow for non-committers to make modifications 
> to categories, milestones, edit the original ticket description, or close 
> tickets. This kinda sucks, because it makes the pool of triagers smaller, and 
> also makes most obvious review queue methods harder (adding a category).
> 
> 
> Are there enough non-committers to Twisted who are actively doing this right 
> now, to make this
> as big an issue as you are claiming?  My guess is no.

"Submit for review" is such an action, so, yes.

> Other projects related to klein and treq are using GitHub to track issues 
> instead of Trac.
> Do those projects have problem with non-committers triaging issues, despite 
> the inability to
> create/modify categories/milestones, etc.?

Yes.  It's a huge issue.  If I didn't have a regular task to manually comb 
those trackers I don't know if anything would get looked at; I have nothing to 
point others at other than "just randomly peruse the list of open issues".  
Trac is hot garbage but I miss it every time I have to look at my 
not-quite-working ad-hoc query to figure out what the workflow state on 
everything there is.

That said: if we could get this ALL into github, then we could write ONE query 
that would be the full review queue for all Twisted org projects.  And that 
would be amazing, a huge upgrade from what we've got now.

Finishing txghbot is probably not a ton of work, but it's not zero either.

-g

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Migrating Trac Tickets to GitHub issues

[Glyph]

> On Sep 30, 2017, at 5:30 PM, Craig Rodrigues  wrote:
> 
> I think migrating Twisted issues from Trac to GitHub is a good idea,
> and will make it easier for people to interact with the project.

To be clear, because I am grumpy about a lot of specifics with respect to GH 
issues: I agree with this and I hope it can happen.

-g

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Migrating Trac Tickets to GitHub issues

[Glyph]

> On Sep 30, 2017, at 2:15 PM, Adi Roiban  wrote:
> 
> Hi,
> 
> I would like to re-start the conversation about migrating Trac tickets
> to GitHub issues.
> 
> My main reason for doing this is to make it easier for people to
> contribute to Twisted.
> 
> In CONTRIBUTING there is this info
> 
> `GitHub doesn't provide adequate tooling for its community.`
> 
> I don't know what is missing in GitHub and why overall Trac is better
> than GitHub issues.

The major missing feature, as discussed in the PR thread, is the ability to 
record the separate workflow state of "needs review" / "needs feedback 
addressed" as distinct from "open" / "closed".  A bot that could do this would 
address more or less the entire issue.

> I know that GitHub Issues is simple and you can't save reports.
> 
> What are problems are there with GitHub issues, which are blocking the
> migration?

One issue which I haven't seen raised here is the need to maintain a 
redirection service, to ensure that the massive amount of information currently 
recorded in commit messages and emails linking to existing trac issues is not 
lost.

> Please send your thoughts.
> 
> Why you think that GitHub issues might be worst than Trac tickets :) ?
> 
> 
> 
> Below are the things that I things we will lose when migrating to
> GitHub Issues and which will require extra work.
> 
> 1. We will no longer get the nice ticket reports.
> 
> I don't know how to get something like this just using GitHub... and I
> think that we will need a separate web page which uses GitHub API to
> create the reports.
> 
> 2. We might lose the owners / authors of some comments as there might
> not be a maping from Trac to GitHub. This might be mititage as we are
> already using GitHub for login.
> 
> 3. There is extra one-time work required to do the actual migration,
> and decide how to translate Trac ticket attributes to GitHub Issue
> attributes.
> 
> We might not get consensus on how to migrate the metadata and this can
> be a blocker.
> 
> 4. We will no longer get the weekly reports and need more work to
> reimplement them based on GitHub.
> 
> 5. Highscores will stop counting the contribution, and it needs more
> work to reimplement it on top of GitHub. I have hacked the highscores
> project and I can change it to work both historic Trac data and new
> GitHub data.
> 
> 
> 
> Below are my arguments for migrating to GitHub issues:
> 
> 1. With Twisted tickets/PR only handled on GitHub you can have
> contributions which are done only by sending a PR, without creating an
> issue. You find a bug, you fix it and send a PR.
> You no longer need to go to Trac and create a ticket and then do all
> the cross-links copy and pasting.
> 
> 2. We no longer have the review history in Trac, and the review
> discussions are split between Trac and GitHub.
> 
> I think that in the future we will move more review discussions in GitHub.
> 
> Having all the discussion in a single place will make it easier to
> search for something.
> 
> You no longer need to search GitHub and Trac tickets.
> 
> 3. With tickets on GitHub we should simplify the infrastructure.
> I feel that lately there was not much time from current Twisted dev to
> take care of Twisted infra.
> From what I can see, the servers are just restarted on an issue, but
> there is no time to investigate what is wrong.
> 
> I think that Twisted dev should focus on Twisted code and not spend
> time with the ticketing infrastructure.

While, in general, I strongly agree with this, and I would personally very much 
like to operate less infrastructure, there is the fact that the 
twistedmatrix.com  website has served as a very 
important dogfooding resource for us in the past.  We've found and fixed dozens 
of bugs in Twisted due to our constant, intense use of it.

That said, this is not really an argument against doing this.  Maybe if we 
didn't have to operate something as old and clunky as Trac we could invest our 
dogfooding effort in new, cool web toys where the effort was writing and 
debugging code using Twisted and not shell scripts to restart zombie processes. 
 I just think it's important to consider how the developer community can 
continue to use Twisted itself as part of this process.

> 4. With tickets in GitHub, we don't need extra tooling to close a
> ticket when a PR is merged.
> 
> 5. With tickets in GitHub I assume that a lot of contributors will
> only have to care about a single management tool: GitHub.
> 
> They will no longer have to learn about Trac, how Trac keywords work
> for a ticket and how a workflow is implemented in Trac for Twisted.
> From what I can see, we are not using the Trac workflows anyway, just
> a hack to implementing something like a workflow by manually setting
> various attributes of a ticket.
> 
> 
> Thanks,

Thanks for driving this effort forward!  I look forward to hearing Mark pipe up 
in this thread (hint, hint)...

> PS: For my privat

Re: [Twisted-Python] Defining the review workflow on top of GitHub PR

[Craig Rodrigues]

On Sat, Sep 30, 2017 at 3:14 PM, Adi Roiban  wrote:

>
>
> orking on a bot to re-open pull requests when a submitter posts a "please
> review" comment: https://github.com/markrwilliams/txghbot



Rather than write a bot specific to Twisted, why not just adapt the Twisted
project to use a bot written by another project?

For example, the Zulip project has written zulipbot:

https://github.com/zulip/zulipbot#zulipbot

Docs for it are here:

http://zulip.readthedocs.io/en/latest/zulipbot-usage.html

and a presentation for it was given here:

http://opensourcebridge.org/sessions/1992

A lot of the motivations for zulipbot are similar to what the Twisted
project is facing:
https://github.com/zulip/zulipbot/wiki/FAQ

such as giving non-committers the ability to add labels to issues or PR's.

zulipbot is actively used, and you can see it in action in their issues and
PR's:
https://github.com/zulip/zulip/issues?utf8=%E2%9C%93&q=is%3Aissue%20or%20is%3Apull

I've met some of the Zulip developers at Pybay.  They are really focused on
improving developer experience and
onboarding of new developers.  Rather than maintain our own bot, the
Twisted project would probably
get further along with zulipbot, and working with the zulip developers to
fill in any missing gaps on that bot.

--
Craig
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Defining the review workflow on top of GitHub PR

[Glyph]

> On Oct 1, 2017, at 12:06 PM, Craig Rodrigues  wrote:
> 
> Rather than write a bot specific to Twisted, why not just adapt the Twisted 
> project to use a bot written by another project?

Personally I don't care either way :-).  I was just describing my understanding 
of the existing plan, not endorsing it.  Hopefully someone more directly 
involved will comment.

-g

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python