search

MeteorPackaging / discussions

Ask for Meteor integration help, or discuss Meteor 3rd party library packaging
5 stars 1 forks source link

Per-repo teams vs. Packagers #3

Open dandv opened 9 years ago

dandv commented 9 years ago

People in the @MeteorPackaging/packagers team, how have the permissions of the team worked fro you so far?

@splendido, can you confirm that your practice so far has been to fork the 3rd party repo into MeteorPackacing, then add the user who requested it to the Packagers team? Mine has been to create a new team per repo, invite the user(s), and give the team full Admin access to its repo(s), so they can add new collaborators. This would keep access separate, but it's a bit more work. Other thoughts?

Also, I think that if we keep adding users to the Packagers team, each will get notified whenever there's activity in any of the repositories that the team has access to. While they can unsubscribe from the notifications, this isn't desirable.

splendido commented 9 years ago

Yes @dandv, I've been a bit lazy and added peple to the Packagers team after having forked new repos I agree it's a better practice to create a new team for each new fork, even this is something that will bloat with time!

I thought every fork would have been deleted (as I already did for some of them) after the integration PR was merged. So maybe having people belonging to the very same team would not have been a problem...

But if we're going to change approach and we'll need to keep all the forks/repos we'll risk to become the GItHub organization with the highest number of repo ever ;-)