[Sugar-devel] Issue tracking on Github?

[Dave Crossland]

Hi Walter!

On 3 April 2016 at 09:04, Walter Bender <walter.bender at gmail.com> wrote:

>
>
> On Sun, Apr 3, 2016 at 12:24 AM, Dave Crossland <dave at lab6.com> wrote:
>
>>
>> On 2 April 2016 at 22:21, Walter Bender <walter.bender at gmail.com> wrote:
>>
>>> I was just asking (again) the other day
>>>
>>
>> Can you provide a URL for where you asked about this? :)
>>
>
> I was asking in a private email with scg who maintains out trac instance.
>

Ah okay, cool :)



> if someone has an issue aggregation tool since our issues are scattered
>>> across multiple repositories. Presumably we are not the first to have
>>> bumped into this problem.
>>
>>
>> I don't understand what you mean :)
>>
>> Assuming that Github is now the central hosting service for Sugar Labs, I
>> expect each logical sugar labs project that is 'official' to have its
>> central git repository hosted in the sugarlabs github organization, and to
>> have its own issue tracker.
>>
>> Since Github automatically places backlinks in issues that are referred
>> to by other issuer or PRs, it is relatively convenient to manage the set of
>> a github organization's per-repo issue trackers.
>>
>> Some free software projects even set up github projects solely to use the
>> issue tracker as a discussion forum, eg https://github.com/ipfs/faq/
>>
>> I believe that all github users that join a github organization will get
>> emailed every issue, pr, and comment for every github project within that
>> github organization.
>>
>> I would also assume that all non-github issue trackers would be
>> configured to prominently direct users to the new github url, and disallow
>> new issues, or simply to have their theme templates hide the 'new issue'
>> link, and eventually to be configured read only and then fully archived by
>> conversion to a static HTML site.
>>
>

Here is the problem as I see it (and as Tony mentioned earlier). A large
> percentage of Sugar code (activity source) is not hosted on
> github.com/sugarlabs, although more and more of it is hosted on github.
>

That seems fine to me, since actively maintained code can be migrated to
Github.

Are there any other places in addition to git.sugarlabs.org and
github.com/sugarlabs?


> So many issues are not found in repos within the Sugar Labs "github"
> organization. How do developers hear about these issues? How do potential
> contributors search for these issues? How do users know where to post an
> issue?
>

I think all 3 questions are answered by co-ordinating a consolidating
migration to Github :)

1. Notification. This is handled due to the way that Github org membership
works; Github-users in a 'developers' Github-team within the
Github-organization will be emailed all posts to all repos that are added
to that team (done here, http://imgur.com/gUTNFfV)

2. Search. Github provides org-wide search, and this is discoverable when
you visit github.com/sugarlabs the search input widget at the top changes
to show that the search is scoped to that organization. After entering a
search query, a familiar search syntax is used in the query, and in the URL
string. Eg, https://github.com/search?q=org%3Afontforge+x11&type=Issues

3. Discoverability. I think that each repo should have its own issue
tracker, and so the url github.com/sugarlabs/activity-name/issues is
predictable. When a repo is moved to the github.com/sugarlabs org, a
checklist could be run over to ensure each activity's /README.md file (that
Github presents on github.com/sugarlabs/activity-name as processed
markdown) has explicit information about the issue tracker.


> If there was a mechanism for aggregating issues across multiple disperse
> repos, we could address most of my issues with migrating from trac.
>

For release management, I think Github doesn't discriminate between
aggregating a list of issues in 1 repo or 1 org or globally in Github.

I used Github in this way in FontForge release management when I was
contributing that labour, eg
https://github.com/fontforge/fontforge/issues/2083


> This is not rocket science, but it is something someone has to build
> and/or maintain. (I just noted in a later thread that you suggest we clone
> all activity repos into the Sugar Labs organization which would address at
> least part of my concern. Still not sure how people search for issues
> across multiple repos.)
>

:)


> (One other trivial question about issues: is there a way to build a
> standardized system of issue tags across multiple repos in an automated
> way? I presume with the github API we could do it.)
>

I'm not sure, but at worst this would be part of the checklist to run
through when accepting a repo transfer into the sugarlabs org.

-- 
Cheers
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160403/12849cc4/attachment.html>