Ok so I've an extra blurb for the licenses, although I didn't add the IP comments since you already had to sign an agreement that states the IP issues when becoming a commiter.
Added some more random notes for the discussion. Thinking so far. New feature [poll], modifed existing feature [vote]. Will need more opinions here. Tiny changes probably don't even need to really be addressed, just commit them. Should we store the new features / feature changes somewhere for easy release messages? On Thu, Apr 18, 2013 at 8:38 PM, Justin Mclean <jus...@classsoftware.com>wrote: > Hi, > > > Ok so while I have been working my new feature through a discussion, I > > wanted to capture our rough process [1] which I have added to a wiki > page. > Looks good so far. Only issue I have is when a new feature is a change to > an existing one - IMO it's more important to see how the code has changed > not the full code. > > We probably need to add something about the files having apache licences > and be able to be licensed. > > > -Is there going to be some sort of sign the feature add can be added to > the > > sdk... e.g. [poll], [vote], or some duration of time that has passed? > Depends on how big the changes is, if it's an addition, does it change > existing behaviour etc etc > > In most cases for small changes and additions it's commit then review but > nice to discuss on list first. > > > -How do we keep track of new features that have been added? Used > primarily > > for when a new release comes out. > JIRA and/svn it's mostly a manual process to convert that to the new > release notes. > > Thanks, > Justin
