I agree. In my case I have example of it's use with view-source [1], a github whiteboard of the modified flex-sdk [2], the code pulled out of the components [3][4][5]. I could change to a diff if that would make things easier.
So now we have steps up to this point. Should a JIRA issue been filed first to allow for a local git branch to be created with that JIRA name and centralize comments on the reviewing? How will the reviewing process go through approval from there? [1] http://people.apache.org/~mkessler/examples/DataProviderEnhance/app.swf [2] https://github.com/KesslerConsulting/example/tree/master/frameworks/projects/spark/src/spark/components [3] http://people.apache.org/~mkessler/examples/DataProviderEnhance/ComponentCode.txt [4] http://people.apache.org/~mkessler/examples/DataProviderEnhance/RegExPatterns.as [5] http://people.apache.org/~mkessler/examples/DataProviderEnhance/IDataProviderEnhance.as -Mark On Mon, Apr 15, 2013 at 8:42 PM, Justin Mclean <jus...@classsoftware.com>wrote: > Hi, > > > I agree, I was doing minor changes, bug fixes and such just CTR. The > > feature addition I have available, I put on the thread first (although I > > did a sloppy job of providing a timely code example) thinking it was a > good > > practice to show before commiting. > > Showing the changes to the code would also help (via git diff or whatever) > that way people can see the scope of the change and makes it easier to > review. > > Thanks, > Justin
