{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/coreclr/issues/744","labels_url":"https://api.github.com/repos/dotnet/coreclr/issues/744/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/coreclr/issues/744/comments","events_url":"https://api.github.com/repos/dotnet/coreclr/issues/744/events","html_url":"https://github.com/dotnet/coreclr/issues/744","id":69654155,"number":744,"title":"How to train your dragon!","user":{"login":"richlander","id":2608468,"avatar_url":"https://avatars.githubusercontent.com/u/2608468?v=3","gravatar_id":"","url":"https://api.github.com/users/richlander","html_url":"https://github.com/richlander","followers_url":"https://api.github.com/users/richlander/followers","following_url":"https://api.github.com/users/richlander/following{/other_user}","gists_url":"https://api.github.com/users/richlander/gists{/gist_id}","starred_url":"https://api.github.com/users/richlander/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/richlander/subscriptions","organizations_url":"https://api.github.com/users/richlander/orgs","repos_url":"https://api.github.com/users/richlander/repos","events_url":"https://api.github.com/users/richlander/events{/privacy}","received_events_url":"https://api.github.com/users/richlander/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":26,"created_at":"2015-04-20T18:45:50Z","updated_at":"2015-04-23T21:58:49Z","closed_at":null,"body":"As you know, the .NET Team, as a broad group, is new to open source. We're doing some things right and other things less so. We might as well just get this out in the open and detail the specific things that  could/would/should go better. It's an issue!\r\n\r\nCertain contributors (*cough* @kangaroo) have been doing an excellent job pointing out various things that MS folks need to change for .NET Core to be a truly successful OSS project. We've been changing some of those things, although maybe not at the scale we should be. I'm sure other folks have ideas too of what could be going better.\r\n\r\nHere's are the specific issues that I've heard. Please pile on, with as much detail as needed (including pointing to PRs and issues as examples). It's OK. Point to the specific examples. It's the only way to fix things. The center of the issue is the firewall between the internal MS process and the GitHub repo and community. We need to remove the firewall, not just open ports in it.\r\n\r\nI've written several detailed points below. I think that they all boil down to this advice for MS engineers:\r\n\r\n> Invest as little time as possible before creating an issue or pushing code to the community. Sharing is a much higher concern than quality.\r\n\r\n- **DO** create issues as soon as possible, even before you fully understand the problem. Self-assign or make up-for-grabs.\r\n- **DO** use public feature branches (personal or central) for work in progress.\r\n- **DO** start work in the open as soon as possible, well before you are done, even before you quite know what you are doing. ```git rebase -i``` and ```git branch -D mybranch``` are your friends.\r\n- **DO** use Issues. **DON'T** use email (as much as possible). Internal technical discussions don't help the community learn and don't enable them to participate. It's like keeping a new hire off of mail threads, for reasons.\r\n- **DO** share snapshots of progress externally on an issue if there is an internal discussion going on. Take a picture of a whiteboard and share it!"},"comment":{"url":"https://api.github.com/repos/dotnet/coreclr/issues/comments/95730878","html_url":"https://github.com/dotnet/coreclr/issues/744#issuecomment-95730878","issue_url":"https://api.github.com/repos/dotnet/coreclr/issues/744","id":95730878,"user":{"login":"kangaroo","id":151532,"avatar_url":"https://avatars.githubusercontent.com/u/151532?v=3","gravatar_id":"","url":"https://api.github.com/users/kangaroo","html_url":"https://github.com/kangaroo","followers_url":"https://api.github.com/users/kangaroo/followers","following_url":"https://api.github.com/users/kangaroo/following{/other_user}","gists_url":"https://api.github.com/users/kangaroo/gists{/gist_id}","starred_url":"https://api.github.com/users/kangaroo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kangaroo/subscriptions","organizations_url":"https://api.github.com/users/kangaroo/orgs","repos_url":"https://api.github.com/users/kangaroo/repos","events_url":"https://api.github.com/users/kangaroo/events{/privacy}","received_events_url":"https://api.github.com/users/kangaroo/received_events","type":"User","site_admin":false},"created_at":"2015-04-23T21:58:49Z","updated_at":"2015-04-23T21:58:49Z","body":"@richlander @ellismg \r\n\r\n> We have always taken the guidance to mean that for changes authored by Microsoft folks, the author counts as one code reviewer. So changes authored by Microsoft folks usually only have one other Microsoft person LGTM them.\r\n\r\nThis is a perfect example of what I meant.  You cannot inherently self code-review.  If the bar to commit is 2 reviews, make it 2 reviews across the board.\r\n\r\n> For changes which are authored internally and mirrored over by the Git -> TFS mirror, we normally do a quick glance to make sure the mirroring process looks reasonable and then merge them. The rationale is they already went through CR internally. Folks are more than welcome to raise issues but we want to merge the code quickly in most cases because we want to keep the trees in sync, so we err towards merge and address feedback later.\r\n\r\nThis should be a long term goal to go away imo.\r\n\r\n> I've seen a handful cases where trivial changes (updates to .md files, changing around .gitmirror files, etc.) are merged without review.\r\n\r\nRules are made to be broken?  Please define trivial so that its clear to everyone.\r\n\r\nAgain, its not about falling down, its about clear and consistent guidelines and contribution bars.\r\n\r\nMake sense?"}}