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?

from micropython.

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.

from micropython.

Also I think that is a problem to have all members as collaborators because we can commit and manage issues.

from micropython.

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/micropython/issues/20#issuecomment-31425281
.

(sent directly from my brain - read at your own risk!)

from micropython.

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.

from micropython.

@wbphelps that's what @dpgeorge wanted but restricted to backers at first. Later he'll make it public.

from micropython.

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:

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

from micropython.

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.

from micropython.

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.

from micropython.

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.

from micropython.

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.

from micropython.

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.

from micropython.

I go with the 'make it open' commenters.

from micropython.

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/micropython/issues/20#issuecomment-31425567
.

Industrial ARMWorks
www.andahammer.com
253 851-0227

from micropython.

It 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

from micropython.

I think 2 (make the repo under an "organization" account) is the best solution. As it doesn't hurt to have an "organization" and make it clear that this is the main repository. The best part is, you don't have to pay once you make it public later on.

Anyway, I am ok with 3 (make it public right now) too.

from micropython.

To be slightly contrary, dealing with a full-on open source community can be a bit of a distraction if he's trying to get all his ducks in a row, and having a multiplicity of ports before he's got the first one fully sorted can have the effect of pouring concrete around premature design choices. (Yeah, I know, porting is also a great way of testing those design choices.)

If it's a matter of a month or three, I'd wait.

On 2014-01-01, at 12:00 PM, Paul Sokolovsky [email protected] wrote:

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.

—
Reply to this email directly or view it on GitHub.

from micropython.

The "normal" thing is to have the organization account with only a few (single digits) active contributors who are trusted with having Push rights to the trunk. They don't generally "push" directly - everyone (including those special high-access contributors) works in their own private or public forks and then submits Pull Requests to the main trunk. At that point one of those limited number of contributors who have Push rights will review the Pull Request and either accept it or send it back.

The whole private fork / pull request / accept or reject process encourages discussion over important commits and is highly transparent - even the comments associated with the individual commits are preserved. It also promotes the use of peer code reviews.

That's how we work on the IronPython team, and it works well there.

from micropython.

How can I stop being subscribed to every fork? I don't want to be
subscribed to all these repo's, much less push access!!!
Yes I know I can unsub. I don't want to be subbed in the first place.
Maybe you should just remove me.
William

from micropython.

On 01 Jan 2014, at 17:42 , Damien George [email protected] wrote:

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…

I don’t have a problem with option 3.

willy

from micropython.

On 2014-01-01 09:42, Damien George wrote:

I'd go for 3, but don't want to take away from those who pledged to have early
access...

I doubt anybody cares about early access. People usually back kickstarter
projects because they want to see a product come to existence. If they can get
an earlier version for a bit cheaper than the final prodcut, then it's all
bonus. To be honest, the fact that you'd open it with a descent license was
one of my concern, and I only backed the project once you confirm you would,
so, yes, please, open it up!

Going with option #3 means using a work flow that everybody is used to. If you
think too much early feedback is going to be an issue, just make it clear that
you will ignore all feedback until a specific date, make it one of the first
point in your "Readme.md". Nobody will hold it against you, your updates have
been pretty amazing, both in terms of frequency and depth of details.

Let's move on this asap, I sure am getting tired of having to unsubscribe from
tens of repos, I'm not even sure which one is the official one now.

Yves.

from micropython.

Under your github account options (the crossed tools in the upper right
hand corner) there's a menu on the left. The second-to-bottom option is
'repositories'; the list on the right hand side when that is selected
indicates the repos you're subscribed to and where that repo was forked
from. Most/all of them will indicate dpgeorge/micropython as the source
repo.

In the 'notification center' option on the left hand side, by the way, you
can deselect the 'email' option so your inbox doesn't explode with a dozen
emails on mornings like this.

-- Dr-Syn

On Wed, Jan 1, 2014 at 11:06 AM, Yves Dorfsman [email protected]:

On 2014-01-01 09:42, Damien George wrote:

I'd go for 3, but don't want to take away from those who pledged to have
early
access...

I doubt anybody cares about early access. People usually back kickstarter
projects because they want to see a product come to existence. If they can
get
an earlier version for a bit cheaper than the final prodcut, then it's all
bonus. To be honest, the fact that you'd open it with a descent license
was
one of my concern, and I only backed the project once you confirm you
would,
so, yes, please, open it up!

Going with option #3 means using a work flow that everybody is used to. If
you
think too much early feedback is going to be an issue, just make it clear
that
you will ignore all feedback until a specific date, make it one of the
first
point in your "Readme.md". Nobody will hold it against you, your updates
have
been pretty amazing, both in terms of frequency and depth of details.

Let's move on this asap, I sure am getting tired of having to unsubscribe
from
tens of repos, I'm not even sure which one is the official one now.

Yves.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/micropython/issues/20#issuecomment-31428089
.

from micropython.

Please create an organization an open the code, the ones that backed for
exclusive early access would understand that's a movement to prevent bigger
chaos.

2014/1/1 Yves Dorfsman [email protected]

On 2014-01-01 09:42, Damien George wrote:

I'd go for 3, but don't want to take away from those who pledged to have
early
access...

I doubt anybody cares about early access. People usually back kickstarter
projects because they want to see a product come to existence. If they can
get
an earlier version for a bit cheaper than the final prodcut, then it's all
bonus. To be honest, the fact that you'd open it with a descent license
was
one of my concern, and I only backed the project once you confirm you
would,
so, yes, please, open it up!

Going with option #3 means using a work flow that everybody is used to. If
you
think too much early feedback is going to be an issue, just make it clear
that
you will ignore all feedback until a specific date, make it one of the
first
point in your "Readme.md". Nobody will hold it against you, your updates
have
been pretty amazing, both in terms of frequency and depth of details.

Let's move on this asap, I sure am getting tired of having to unsubscribe
from
tens of repos, I'm not even sure which one is the official one now.

Yves.

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/micropython/issues/20#issuecomment-31428089
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

Okay, I've created an organisation called "micropython". I can make 2 repositories to start with: the code (software/firmware), and the board (hardware). The code will be called "micropython".

Sorry for the mess with this initial set up!

from micropython.

Don't worry, we probably would have get the same errors on your situation
:-) At least we have learned the lesson for the next one ;-)

2014/1/1 Damien George [email protected]

Okay, I've created an organisation called "micropython". I can make 2
repositories to start with: the code (software/firmware), and the board
(hardware). The code will be called "micropython".

Sorry for the mess with this initial set up!

—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/micropython/issues/20#issuecomment-31428447
.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

I transferred the repo to github.com/micropython/micropython . I think everything remained intact. It's public so you can all access it.

from micropython.

Nice, thanks @dpgeorge

from micropython.

Any suggestions how I should set up the teams in the organisation? I would like to give people pull access so they can edit the wiki. Do people want to be added to a "pull team"?

from micropython.

AFAIK, default setting of a project is that everyone with a github account can edit wiki. So, you can just (re)set it to such until spam ensues (I never saw spam in github wiki, keeping fingers crossed).

from micropython.

@pfalcon that seems to be correct (that any GitHub user can edit the wiki) and I've set the option so that this is allowed for micropython.

from micropython.

Ack... Yeah, I think I spent a hour just going though my email, which btw I don't expect too much of github stuff in.
The original allowing of viewing and forking from the original repo is fine, but when I get re: allows from anyone involved as a backer, then this is quickly going to get out of hand.
I never experienced this type of issue before, but Thanks for looking into this.

I dont care for push access to the main repo. I/Most backers just wanted to view and fork their own branchs, which if or whenever the time comes to contribute something, then a pull request is the way to go about it.

I think a standard public wiki is a fine idea also. Most folks can set up free wiki/blog pages also for little offspin projects and bits of code related to microcontrollers and python.

Until you actually get the boards into the backers and publics hands(march-ish), then you shouldn't get too much
spam from noobs and otherwise folks just browsing for code. Just make it plain on the main pages that this IS for microcontrollers and until march or whenever only backers will get tech/official support(or whatever (the real reward is actually the board itself anyway)) maybe with exceptions for those donating code to help the micropython side of the project.

So, I assume everyone involved needs to refork from github.com/micropython/micropython
...? Is this correct?

from micropython.

So, I assume everyone involved needs to refork from
github.com/micropython/micropython
...? Is this correct?

Not really, relating to the pull requests GitHub forks will be
automatically updated to point to the new repo.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

from micropython.

It seems this issue has been well resolved and can be closed now?

from micropython.

Yes, close it. This is resolved.

from micropython.

It keeps to know how to be removed from all the forks, my GitHub daahboard
sucks with all of them, it's confusing and dificult to find the project you
want to go... :-(

Send from my Samsung Galaxy Note II
El 05/01/2014 12:27, "Jonathan Greig" [email protected] escribió:

Yes, close it. This is resolved.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-31601862
.

from micropython.

@piranna To leave the forks just go to Account settings > Repositories, and then click leave on them.

from micropython.

I was looking directly on each project :-P Thanks! :-D

Send from my Samsung Galaxy Note II
El 05/01/2014 13:13, "Sergio Conde Gómez" [email protected]
escribió:

@piranna https://github.com/piranna To leave the forks just go to
Account settings > Repositories, and then click leave on them.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-31602686
.

from micropython.