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

Migrate to an organizational structure #1867

Open
rickstaa opened this issue Jul 14, 2022 · 8 comments
Open

Migrate to an organizational structure #1867

rickstaa opened this issue Jul 14, 2022 · 8 comments
Labels
proposal Proposals to change code or documentation fundamentals.

Comments

@rickstaa
Copy link
Collaborator

rickstaa commented Jul 14, 2022

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:

  • Github-readme-stats: (fetchers, stats, language, repo cards and core card generation functions)
  • gitlab-readme-stats: (fetchers, stats, language, repo cards)
  • wakatime-readme-stats: (fetcher, waketime card).
  • leetcode-readme-stats: (fetcher, leetcode card).

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.

@rickstaa rickstaa added the proposal Proposals to change code or documentation fundamentals. label Jul 14, 2022
@rickstaa rickstaa changed the title Migrate to using a organization Migrate to an organizational structure Jul 14, 2022
@rickstaa
Copy link
Collaborator Author

We can, of course, also release the core functionality under an npm package without moving to an organization. 👍

This was referenced Jul 23, 2022
This was referenced Sep 16, 2022
@rickstaa
Copy link
Collaborator Author

rickstaa commented Oct 7, 2022

I created #2151 to make the functions and modules under the common folder available to be used via an npm package.

@Zo-Bro-23
Copy link
Collaborator

+1 for this! Having multiple repos might be cumbersome though; maybe we can use the APIs from #2409...

@rickstaa
Copy link
Collaborator Author

+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. 👍

@Zo-Bro-23
Copy link
Collaborator

I'm not sure how easy it is to migrate given the Vercel instance that is linked

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.

@rickstaa
Copy link
Collaborator Author

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. 😅

@Zo-Bro-23
Copy link
Collaborator

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! +1 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. sweat_smile

Makes sense. It'd be much easier if I was able to close/label issues and prs!

@rickstaa
Copy link
Collaborator Author

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! +1 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. sweat_smile

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! 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Proposals to change code or documentation fundamentals.
Projects
None yet
Development

No branches or pull requests

2 participants