Skip to content

Settings and activity

2 results found

  1. 6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Chris McElligott Park shared this idea  · 
  2. 30 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  General  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    Chris McElligott Park supported this idea  · 
    An error occurred while saving the comment
    Chris McElligott Park commented  · 

    Very curious if this is on the horizon. This is something I've taken for granted the last decade or so with repositoryhosting.com, for example.

    On any distributed team that is large at all (not to mention multi-OS), having individual users running complex programs on triggers is not feasible. Also, just trying to update the email lists for them all would be infeasible -- some email addresses are not intended to be shared with every contractor with commit rights, but their commits should still go into the pool, etc.

    I don't think this needs to be super overengineered. Essentially, a few basics would accomplish most things:

    - Does a plastic scm cloud user have access to a project? Was there a checkin to the project? Email them unless they opt out.

    You can get fancier with things like email addresses that are not part of the list of cloud users, or you could get into things like branches only going to be people related to the branch, but this is not too terribly critical for small and midsize teams.