Re: GitHub PR status within Trac

2016-07-25 Thread Tim Graham 
If the goal is to provide a list of issues suitable for new contributors, I 
think a curated list of tickets is likely more useful than trying to 
automate something. Looking over the list of "Has patch" + "Needs 
improvement" tickets, it seems to me that most of those PRs fizzled out for 
non-trivial reasons. Going forward, I'll check "Easy pickings" on tickets 
where I close the PR due to inactivity and where only straightforward 
updates remain.

On Friday, July 22, 2016 at 7:13:52 PM UTC-4, Carl Meyer wrote:
>
> Hi Tobias, 
>
> On 07/22/2016 04:53 PM, Tobias McNulty wrote: 
> > I spent some time during the DjangoCon sprint today looking into 
> > dashboard.djangoproject.com  and 
> how 
> > it calculates metrics. I was hoping to add some new metrics that mash up 
> > data from GitHub and Trac together. While technically possible, this 
> > breaks down when you want to link out to a list of the related tickets 
> > in Trac. For example: 
> > 
> >   * A list of Accepted tickets with no open PR or an open PR that hasn't 
> > t been touched in X months 
> >   * A list of Accepted tickets with no PR and no attached patch that 
> > haven't been touched in  months 
> > 
> > This got me wondering: Is checking for GitHub PRs via JavaScript the 
> > Right Way to do it? What if we had a cronjob update Trac periodically 
> > with PR status from GitHub? 
> > 
> > I think it would be valuable to be able to query on PR status from 
> > within Trac, e.g., to help find in progress but stale/abandoned tickets. 
> > Cleaning up the work of someone else who's lost interest in a patch is 
> > often a good way to get into Django development. 
> > 
> > I'm sure there are some holes in this idea, so I'm putting it out there 
> > for comment. Was something like this considered before, and if so, why 
> > wasn't it pursued? 
> > 
> > If it hasn't been considered before, what are the obvious problems I 
> > might encounter? 
>
> Others know these systems better than I do, but just a couple thoughts: 
>
> 1) While being able to query Trac by PR status would be useful, losing 
> the immediate feedback of "I just created my PR and reloaded the Trac 
> ticket, and there it is!" would be a significant loss, I think. Delays, 
> even of just a few minutes, in that sort of UI tend to introduce an "is 
> this actually working" uncertainty that leads to extra support queries. 
> So maybe even if you implemented something on the backend, we shouldn't 
> get rid of the JS code? Or maybe github push hooks could be used to keep 
> update latency low? 
>
> 2) I think it was done this way originally because whoever did it was 
> scared of touching Trac's Python code (with reason), and it was simpler 
> to just do it in JS, not for any deeper reason. 
>
> Carl 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8c220d4c-b2fb-46cc-b207-b75b14ee3e8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub PR status within Trac

2016-07-22 Thread Carl Meyer 
Hi Tobias,

On 07/22/2016 04:53 PM, Tobias McNulty wrote:
> I spent some time during the DjangoCon sprint today looking into
> dashboard.djangoproject.com  and how
> it calculates metrics. I was hoping to add some new metrics that mash up
> data from GitHub and Trac together. While technically possible, this
> breaks down when you want to link out to a list of the related tickets
> in Trac. For example:
> 
>   * A list of Accepted tickets with no open PR or an open PR that hasn't
> t been touched in X months
>   * A list of Accepted tickets with no PR and no attached patch that
> haven't been touched in  months
> 
> This got me wondering: Is checking for GitHub PRs via JavaScript the
> Right Way to do it? What if we had a cronjob update Trac periodically
> with PR status from GitHub?
> 
> I think it would be valuable to be able to query on PR status from
> within Trac, e.g., to help find in progress but stale/abandoned tickets.
> Cleaning up the work of someone else who's lost interest in a patch is
> often a good way to get into Django development.
> 
> I'm sure there are some holes in this idea, so I'm putting it out there
> for comment. Was something like this considered before, and if so, why
> wasn't it pursued?
> 
> If it hasn't been considered before, what are the obvious problems I
> might encounter?

Others know these systems better than I do, but just a couple thoughts:

1) While being able to query Trac by PR status would be useful, losing
the immediate feedback of "I just created my PR and reloaded the Trac
ticket, and there it is!" would be a significant loss, I think. Delays,
even of just a few minutes, in that sort of UI tend to introduce an "is
this actually working" uncertainty that leads to extra support queries.
So maybe even if you implemented something on the backend, we shouldn't
get rid of the JS code? Or maybe github push hooks could be used to keep
update latency low?

2) I think it was done this way originally because whoever did it was
scared of touching Trac's Python code (with reason), and it was simpler
to just do it in JS, not for any deeper reason.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e70012b5-dd03-526a-6f99-a03470332bae%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

GitHub PR status within Trac

2016-07-22 Thread Tobias McNulty 
I spent some time during the DjangoCon sprint today looking into
dashboard.djangoproject.com and how it calculates metrics. I was hoping to
add some new metrics that mash up data from GitHub and Trac together. While
technically possible, this breaks down when you want to link out to a list
of the related tickets in Trac. For example:

   - A list of Accepted tickets with no open PR or an open PR that hasn't t
   been touched in X months
   - A list of Accepted tickets with no PR and no attached patch that
   haven't been touched in  months

This got me wondering: Is checking for GitHub PRs via JavaScript the Right
Way to do it? What if we had a cronjob update Trac periodically with PR
status from GitHub?

I think it would be valuable to be able to query on PR status from within
Trac, e.g., to help find in progress but stale/abandoned tickets. Cleaning
up the work of someone else who's lost interest in a patch is often a good
way to get into Django development.

I'm sure there are some holes in this idea, so I'm putting it out there for
comment. Was something like this considered before, and if so, why wasn't
it pursued?

If it hasn't been considered before, what are the obvious problems I might
encounter?

Rather than sync the data periodically, another approach might be to extend
the existing trac-github 
plugin, though that would still require sync'ing existing data up front and
substantial testing to make sure all the right events (e.g., renames and
closures) are caught appropriately. It's not as simple as adding a commit
hash to a ticket's history, esp. if we ever wanted to change the fields
that were brought over from GitHub.

Tobias
-- 


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMGFDKS9LkX6wAXP_gEroQAs_0uf2Q3qLWON_thTupxmDW9XGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.