ius-community team mailing list archive

[BJ Dierkes <derks@xxxxxxxxxxxxxxxx>]

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] team@xxxxxxxxxxxxxxxx


On February 4, 2015 at 11:44:10 AM, Ben Harper (ben.harper@xxxxxxxxxxxxx) 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] team@xxxxxxxxxxxxxxxx  
> [m] 210.367.2599  
>  
> On February 3, 2015 at 3:51:32 PM, Carl George (carl.george@xxxxxxxxxxxxx) 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.com@xxxxxxxxxxxxxxxxxxx] on behalf of BJ Dierkes [derks@xxxxxxxxxxxxxxxx]  
> Sent: Tuesday, February 03, 2015 03:30 PM  
> To: Ben Harper; ius-community@xxxxxxxxxxxxxxxxxxx  
> 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] team@xxxxxxxxxxxxxxxx  
>  
>  
> On February 3, 2015 at 10:29:57 AM, Ben Harper (ben.harper@xxxxxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxx  
> Unsubscribe : https://launchpad.net/~ius-community  
> More help : https://help.launchpad.net/ListHelp  
>