-
-
Notifications
You must be signed in to change notification settings - Fork 23.2k
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
Migrate to an organizational structure #1867
Comments
We can, of course, also release the core functionality under an npm package without moving to an organization. 👍 |
I created #2151 to make the functions and modules under the |
+1 for this! Having multiple repos might be cumbersome though; maybe we can use the APIs from #2409... |
@Zo-Bro-23, thanks for your support! I messaged @anuraghazra about the organization structure. I'm not sure how easy it is to migrate given the Vercel instance that is linked but I think it would better allow the community to maintain this project. 👍 |
There shouldn't be any problems. Vercel can handle organizational repos; you just need a team plan (which I believe you already have); see this. |
We don't need multiple reports. That was just a suggestion to decrease the load on the PATs. On second thought, I'm also fine with keeping one repo! 👍 I just wanted to have the community more involved by having the ability to add different collaborators with different permissions. Currently, this repo is maintained by @rickstaa and @anuraghazra, which becomes harder now that the repository is so popular. 😅 |
Makes sense. It'd be much easier if I was able to close/label issues and prs! |
I agree! I texted @anuraghazra your offer to help! 🚀 |
Is your feature request related to a problem? Please describe.
We often get card requests from users that want to add new cards (i.e., #1563 and #1786). Currently, we have to decline these requests due to GitHub's rate limits and maintainability concerns (see #1563 (comment)).
Describe the solution you'd like
Splitting up our codebase to separate repositories under the readme-stats repository could solve this. This would allow users to implement their cards and transfer them to the organization for maintenance. I would therefore like to propose a structure like this:
I know this is a significant design change, but after #1633 is complete, we can move our card creation code to a separate npm package so users can use it to create their cards. An additional benefit of such a structure would be to include more maintainers since organizations allow for more precise permission management.
The text was updated successfully, but these errors were encountered: