Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rationalize GitHub-vs-portal-based team join requests #151

Open
jeffwilcox opened this issue Jul 14, 2020 · 1 comment
Open

Rationalize GitHub-vs-portal-based team join requests #151

jeffwilcox opened this issue Jul 14, 2020 · 1 comment
Assignees
Labels

Comments

@jeffwilcox
Copy link
Contributor

Before GitHub implemented team join requests many years ago, this portal had the concept
of a team join request.

A key difference, and why we are still using the in-portal experience primarily, is that at scale,
with thousands of users, it's difficult to understand "who, what, why" on these sorts of requests.

The in-portal experience differs from GitHub: GitHub simply has a "join" button, which tells the
team maintainers to approve the request. The portal experience has a "justification" free-form
text box, to allow the requester to provide context. The approve and deny experience also
lets the person making the decision document why they made the decision, to inform the user.

Across over 100,000 requests we have had in many years, over 21,000 of the requests were
denied.

A majority of the requests are because people want to contribute to a repo, something they can
do just fine with a fork and pull request, for example.

So potential work here:

  • Show GitHub-based team requests in the portal UI
  • Consider dropping the context-based in-portal experience
  • Consider keeping the separate approach, with metadata, on top of a native join experience on GitHub
  • Other ideas
@github-actions
Copy link

This issue has been identified as stale because it has gone 30 days with no activity.
The issue will be closed in 10 days. If this is incorrect, simply comment on the issue, or remove the stale label.

@github-actions github-actions bot added the Stale label Oct 11, 2022
@jeffwilcox jeffwilcox self-assigned this Oct 11, 2022
@jeffwilcox jeffwilcox added keep-me and removed Stale labels Oct 11, 2022
garnertb pushed a commit to DevOptimusPrime/opensource-management-portal that referenced this issue May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant