Support for nested teams

Issue #288 new
Edward Zarecor (Do Not Use) created an issue

Looking at the docs, site and readmes I don't see an reference to a Slack or IRC channel for discuss feature requests or the roadmap. So, I'm asking here.

Minimally, I'd like to have the ability to either or both:

  • Add teams to teams, for example, security team and feature team are members of the "all engineers team"
  • Associate multiple teams with a project

What's the best way to discuss enhancement requests, we can potentially contribute code, but don't want to work on this if it's not directionally alligned with your roadmap.

Comments (3)

  1. Robert Reiz

    @e0d We can discuss it here. The Roadmap is influenced by paying customers. There are some large companies who use VersionEye as on premise solution and they pay a lot of Money for support. Feature requests from them are implemented first of course. So far non of the top paying customers asked for nested teams. I personally also don't see a lot of value in it. I like flat hierarchies. Maybe adding labels to teams would be a good way to filer for them. What do you think? There are different options now:

    • You fork the project from GitHub and implement it by yourself and send back a pull request.
    • You could use the VersionEye API to fetch projects and teams and add another layer to it and build a different UI on top of the API.
    • You pay me for implementing this feature.
    • You wait until a large company pays me to implement this feature.
    • You wait until I have nothing else to do and I'm so bored that I implement it just for fun.

    Let me know what you think.

  2. Edward Zarecor (Do Not Use) Account Deactivated reporter

    @reiz As I said, this is something we would consider working on, but divergent forks are in no one's interest. Significant OSS undertakings don't, in my opinion, make sense unless there's agreement about the value up front, which is what I was hoping to establish or "dis-establish."

    I think that nested teams are useful because they improve usability and security.

    For example, at edX, www.edx.org, we have a DevOps team. That team needs to get notifications for 80% of our 200 repos.

    If nested teams or multiple teams are supported per project, I can add a new DevOps resource to the DevOps team and they have access to every repo the other DevOps folks already have access to. The same happens when I remove them.

    I assert this also improves security because it's less error prone to remove someone from one group than n.

  3. Robert Reiz

    Hi @e0d nested teams are not implemented yet, but the data model supports already multiple teams per project. Currently the UI allows only 1 team per project, but extending that to multiple teams would be not a huge amount of work and would somehow make sense.

  4. Log in to comment