We have made changes to the app on the 29th of June release:
Added the ability to run CI jobs belonging to other users if the source is a git repo and the target has deployment access delegated.

We think this now covers the cases:
- Allow user to run other people's org to org CI jobs
- Allow user to run other people's git to org CI jobs

We have not implemented allowing user to run other people's org to git CI jobs. As this is sub use case is quite a specific interpretation of the original suggestion. Perfectly happy for it to be specified in another separate suggestion.

We have updated the documentation to reflect this change - https://docs.gearset.com/en/articles/2533179-access-levels-in-gearset

I hope this delivers the what your team needs. Feedback always welcome :)

as mentioned from Pablo 16. Oktober 2018:
You might consider to implement the sharing at a CI job level since we might not want to share the GIT credentials, we wouldn't like people committing changes to repo on behalf of another user. That's what will happen if the sharing of the GIT credentials is required to be able to run a CI job.

In our case, we want users to be able to retrieve metadata and commit their changes to the repository but not to deploy these changes from the repo to another org because, often, people make mistakes selecting a different filter or API version. We avoid that if they have the possibility to run a specific job to have their changes deployed from the repo to the org desired, ensuring that the correct settings are used.

We need this.

Thank you for the feedback guys!

We are seeking a bit of clarification here:
As documented in https://docs.gearset.com/en/articles/2533179-access-levels-in-gearset

Team owners can already run CI jobs they do not own, as long as both the source and target are orgs and not git branches. Team owners still require the correct delegated org access in order to run automation jobs.

Is the suggestion specifically about CI job with git environments? If so, we'll update the suggestion description to clarify the situation.

Super Heros R Us comment showcases the usefulness.

Really needed

Please, we need this to be more agile in our development

It is important for a Pro user as well.

Here are our use cases that support this suggestion.

Execute Others’ Validate Only or CI Jobs

Jane Smith creates the weekly CI Job for Super Heros R Us. It is validating the code in a github repo targeting a SF Org. She has set up access to GitHub using her personal account.

John Doe, a member of the same Gearset team, is responsible for doing the weekly deploy for SuperHeros R Us as Jane is out sick. There is an issue with Jane's job. It turns out that they need to only selectively deploy certain components this week due to changes made in target org from other teams. He is unable to modify or execute Jane's job so he either has to duplicate it or do the deploy via SF.

Let team members run CI job

This feature will be useful if there are multiple release team members working from different Geographic locations.

Also, I can have one CI job for CI environment based on commit, can have another CI job to TEST environment (has to be manually triggered when I want to push changes to TEST).

You might consider to implement the sharing at a CI job level since we might not want to share the GIT credentials, we wouldn't like people committing changes to repo on behalf of another user. That's what will happen if the sharing of the GIT credentials is required to be able to run a CI job.

In our case, we want users to be able to retrieve metadata and commit their changes to the repository but not to deploy these changes from the repo to another org because, often, people make mistakes selecting a different filter or API version. We avoid that if they have the possibility to run a specific job to have their changes deployed from the repo to the org desired, ensuring that the correct settings are used.

It should be possible to share CI jobs regardless the credentials behind instead of having to grant access independently to each team member both source and target credentials. It would be nice to have the possibility to share the job with all team members easily or select some of them no matter the licence either, what would you make a difference between Pro or Enterprise?
Currently, this idea was announced as a release change already done but the current implementation doesn't represent what this idea should be since, at the moment, you can just share a CI job that are ORG to ORG, not GIT -> ORG (since you can't share GIT credentials at the moment).

Why would you not be able to run a CI job? Lets take this scenario. Co-worker creates a CI Job that sends changes from git to a central Salesforce sandbox. This run automatically when changes are merged from the Pull Request. But say, that build fails to deploy for one reason or another, and that person is on Vacation for the week? We can no longer kick off those CI Jobs that we are dependent on. I don't see how this is not something that is standard functionality.

At least have an option where you can grant permission to users to give the ability to run specific jobs they do not own.

We are using manually push CI jobs that we keep in disabled mode. By disabling them, it allows us to keep a deployment with a set filter and deploy when we best see fit.