Repository navigation
Forked repo adding all members. #20
Description
Activity
I get these too, I think everyone does...
Maybe this whole thing is going to get out of hand, having everyone a "collaborator". I wanted to give backers private access to the code, and, without creating an "enterprise project", this was the only way I could get it working.
I also wanted people to be able to edit the GitHub wiki.
Any suggestions?
Yep, I noticed it. Sorry here, I made a fork to make some tests but I've deleted it as soon as I noticed it.
Now I'm using my private server.
Also I think that is a problem to have all members as collaborators because we can commit and manage issues.
I contribute to several repos on Github. Usually people fork a repo, make
their changes, and then the owner can merge them back in. Why not just keep
it that way?William
On Wed, Jan 1, 2014 at 8:24 AM, Sergio Conde Gómez
notifications-at-github.com |github/Allow William| <
[email protected]> wrote:Also I think that is a problem to have all members as collaborators
because we can commit and manage issues.—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/20#issuecomment-31425281
.(sent directly from my brain - read at your own risk!)
Any suggestions?
I did mine long time ago - after so successful Kickstarter project, please open up project ASAP and enjoy community-building and fame ;-). I understand that these may lead to feedback avalanche which may take away your cycles, but as a benevolent dictator, you can listen and respond per your own schedule. And well, the sooner it starts, the sooner it stabilizes.
Eventually it'll be a public repo. The reason to keep it private was to give backers early access (their reward!) and limit the feedback initially so I have time to code!
Okay then, I see 3 options:
- Keep it as is, private with collaborators, and just trust people to not send bulk emails.
- Re-do the repo and make it an "organization" account so everyone can have read-only access (but open issues and edit the wiki).
- Just make it public right now.
I'd go for 3, but don't want to take away from those who pledged to have early access...
If I had to vote I prefer the 3rd option.
Personally I didn't pledged for early access (although I wanted to have a look into your code and mess with it).Maybe you should do a little update in the kickstarter project (only for backers) and make a vote.
While it's a bit annoying being added to all the forked repositories it isn't too hard to go to "Account settings - Repositories" and select [leave] for any you don't feel like keeping. Or just select "Ignore" in the [watching] option of a repository so you don't get news and updates.
Just make it public right now.
I'd go for 3, but don't want to take away from those who pledged to have early access...Gentlemen who pledged on Kickstarter campaign - do you feel that you would lose anything if project goes open-source right away vs later? Note that choosing "later" means artificially throttling MicroPython progress, growth, community adoption. Damien has very specific product(s) in development and will concentrate on them. Do you want Arduino Due port, support for your particular hardware module, etc.? Nobody is going to do it, except community. And if only every 20ith of people who will look at the code will actually hack on it, then thousands and thousands need to get access to it. It takes time anyway, so sooner it starts, the better - for everyone.
I didnt pay for early access either, but that was only cuz I could see the benefit. I think it should go open ASAP and have our wonderful community contribute.
I don't have a problem with the code going public early. I think it's more important to have a clean master where Damien controls what gets added so the project doesn't get out of control.
I go with the 'make it open' commenters.
3 is fine by me. I have a big public project going and use an org with 5
or 6 members who can look at pull requests.
-- Charlie
On Wed, Jan 1, 2014 at 8:42 AM, Damien George [email protected]:
Eventually it'll be a public repo. The reason to keep it private was to
give backers early access (their reward!) and limit the feedback initially
so I have time to code!Okay then, I see 3 options:
Keep it as is, private with collaborators, and just trust people to
not send bulk emails.
2.Re-do the repo and make it an "organization" account so everyone can
have read-only access (but open issues and edit the wiki).
3.Just make it public right now.
I'd go for 3, but don't want to take away from those who pledged to have
early access...—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/20#issuecomment-31425567
.Industrial ARMWorks
www.andahammer.com
253 851-0227It needs to be set it up as an organization which is called micropython so that it is absolutely clear that it is the "upstream" repo and Damien can still choose who has push access. I.E. The org/repo would look like this: https://github.com/micropython/micropython
I am one of the developers for Embroidermodder and this is exactly how we have it setup: https://github.com/Embroidermodder/Embroidermodder
27 remaining items
- added a commit that references this issue
on Feb 14, 2021 - added a commit that references this issue
on Apr 25, 2024 - added a commit that references this issue
on Sep 21, 2024 - added a commit that references this issue
on Nov 21, 2025 - added a commit that references this issue
on Feb 5, 2026 - added a commit that references this issue
on May 23, 2026 - added a commit that references this issue
on Sep 21, 2026
I don't know about you guys, but I have received a bunch of emails about being added to everyone's forked repos. I don't want to be added to everyone's fork. I don't know if this is an automatic feature of github, but please figure it out!