Ideally, I think the best solution would be: * Turn *off* issues/wiki/etc on all of the iuscommunity-pkg/XXX repos. * Every repo would have a README.md that would include a link to "iuscommunity/support” (or whatever its called) * All issues, package related or otherwise, would go through “iuscommunity/support”
I just think that having issues spread out across dozens/hundreds of repos will make things more complicated. It’s easier to manage to have a singular link. “To report issues go HERE” rather than “to reports issues for pkg-XXX go HERE-XXX but to report issues for pkg-YYY go HERE-YYY"… Really, all the repos under iuscommunity-pkg are internal use. End-user’s don’t need to care where the data lives for ‘php54u’ … the easier it is to engage people, the more likely it is they will engage. Again, its a design issue with this use-case of GitHub so kinda just duct-taping it up to work for us. All that said, I’m not involved with the day-to-day anymore so it might make more sense to manage issues individually across all the repos. But that just like, my opinion man. ;) --- BJ Dierkes Data Folk Labs, LLC [w] http://datafolklabs.com [e] t...@datafolklabs.com On February 4, 2015 at 11:44:10 AM, Ben Harper (ben.har...@rackspace.com) wrote: BJ, that is a good point. Having a straight forward way for community members to submit issues is important. I think there might be a few creative solutions that might make it workable. The initial iuscommunity/wishlist was created as a starting point for testing. The README.md needs updating and would need detailed information about the preferred location to submit an issue. If you have a bug for php54 then submit it to the php54 repo. If you have a package request, general question or not sure where to file an issue, the iuscommunity/wishlist repo (or other name) can be used. The down side to for using that repo for catch all is GitHub does have a way to move an issue to a different repo. Looks like github-issues-import[0] could be a work around for this problem, although not the most elegant approach. -Ben [0] https://github.com/IQAndreas/github-issues-import On 02/03/2015 04:01 PM, BJ Dierkes wrote: > Yep… you can view them… but there are no end-user controls to say… create an > issue, etc. It’s just a high level overview that links you to the individual > project/repo. Not really a feasible option unfortunately. > > --- > BJ Dierkes > Data Folk Labs, LLC > > [w] http://datafolklabs.com > [e] t...@datafolklabs.com > [m] 210.367.2599 > > On February 3, 2015 at 3:51:32 PM, Carl George (carl.geo...@rackspace.com) > wrote: > > The Github issue dashboard does allow you to view issues at the organization > level, or even multiple organzations. > > https://github.com/issues?q=is%3Aopen+user%3Aiuscommunity+user%3Aiuscommunity-pkg > > > The search syntax is documented here. > > https://help.github.com/articles/searching-issues/ > > Carl George > Rackspace GNU/Linux Engineer > From: Ius-community > [ius-community-bounces+carl.george=rackspace....@lists.launchpad.net] on > behalf of BJ Dierkes [de...@datafolklabs.com] > Sent: Tuesday, February 03, 2015 03:30 PM > To: Ben Harper; ius-community@lists.launchpad.net > Subject: Re: [Ius-community] Possible change from LaunchPad bugs to GitHib > issues > > Ness and I had this same dilemma back in the day. Super annoying in this use > case that GitHub doesn’t have issue tracking at the organization level. What > we don’t want is managing bugs/feature requests across 300 repos for every > package. Need everything in one place, however I don’t think that “wishlist” > is the best terminology. I think we should have a single project for managing > all interaction with community including bugs, feature requests, wishlist > items, etc. Those should all be tags/labels under the same project. > > I would suggest “iuscommunity/support” which covers all that pretty > generically…. or something similar. > > --- > BJ Dierkes > Data Folk Labs, LLC > > [w] http://datafolklabs.com > [e] t...@datafolklabs.com > > > On February 3, 2015 at 10:29:57 AM, Ben Harper (ben.har...@rackspace.com) > wrote: > > Greetings, > > The ius-coredevs have been debating if IUS should switch from using > LaunchPad bugs to GitHib issues. We have really been enjoying GitHib > for source control and GitHib does a good job integrating issues with > source control and pull requests. Unfortunately, Github does not have a > native way to submit an issue for an entire organization for things like > new package requests. We are currently testing a dedicated repo for new > package requests[0] and are looking for feedback. Please let us know if > you have any thoughts about moving away from LaunchPad bugs and to > GitHib issues. > > -Ben and the rest of the IUS covedev team > > > [0] https://github.com/iuscommunity/wishlist > > _______________________________________________ > Mailing list: https://launchpad.net/~ius-community > Post to : ius-community@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ius-community > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~ius-community Post to : ius-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~ius-community More help : https://help.launchpad.net/ListHelp
