Workshop BEK March 2014 Thursday

Thursday, 6 March

Present: Trond, Adrian, Tim, Theo, Nathan, Henrique (after updates)

##Updates

We began at 10:15 with individual updates on what we have been working on during our time in Bergen. Nathan described his work on the Ruby build script over the last two days (Core Issue #210). All this should enable cross platform compilation while still maintaining a single YAML file of the dependencies.

Theo has worked on re-naming j.remote, has setup a Core test application, and implementing other changes that were discussed during that last few days.

Tim worked almost exclusively on getting Windows version to build (in collaboration with Theo). This begged the question: After the workshop, who will take responsibility for the Windows build? Theo said that Laurent Garnier of Blue Yeti will be working here, but he needs to be check regularly against the latest changes especially in the build scripts. It is great they have interest in Windows, but we ideally would like them to take responsibility for a public build and not just one they use themselves.

Adrian has been porting a module that is done, but still working on the corresponding help patch. He is also working on a javascript that will allow Max windows to be linked on the screen and have them work like a consistent interface.

Pascal has been updating modules and models based on decisions made during the workshop.

Trond has been working on various things, mostly running the workshop and authoring a few blog posts.

Henrique arrived after updates so we did not hear from him directly, but he has automated several aspects of the workflow between Github and the BEK servers.

##Workflow

About 10:30 we returned to the BOD section of our initial agenda. We settled into a discussion on workflow and how we can improve things for ourselves to make development more rewarding and hopefully encourage more developers to get on board.

Issues raised:

• Too often we gravitate toward big changes. Future development needs to emphasize more incremental changes.
• We also have a habit of starting changes, but not finishing them. We need to have greater accountability and collaboration to make sure things are followed through to completion.
• When discussing major new features and changes, we need to discuss not only specifications and implementation, but also how we intense to implement them.

Guidelines going forward:

• Milestones need to be achievable, therefore smaller. Probably 12 to 15 issues per milestone.
• Primarily focus should be on milestones, which means sometimes we let "fires burn". One purpose of this is to protect Tim and Théo from being pulled in too many directions.
• We will have two kinds of meetings: sprint-related and proper BOD relating to the larger and long term/strategic development. The latter needs to have a general attendance, and need to strive for decisions based on consensus.
• Sprints should be coordinated at board meetings, then continue via meetings and communications with smaller teams.
• Board meetings must be at least every second month and have a defined agenda in advance.

We discussed version numbering and spent some time considering whether this is version 0.6 or 1.0? Ultimately, we decided this is 0.6. Some elements of the discussion:

• Pascal pointed to this reference to this resource on version numbering. General feeling that things should be more tidy for 1.0.
• We need to think of version number separately for each submodule: Core and the various implementations. Our tagging practice has been changed to cater for this.
• Let’s start to think of 0.6 as last version before 1.0. We can then define certain milestones as "before 0.6" or "0.6 to 1.0 transition".

At 11:00, we transitioned to Issue tracking. Trond gave an overview of how he has reorganized the labels and milestones on Github. We agreed that Trond should act as the overall Jamoma project manager and will take the lead on organizing meetings and sprints via Github milestones.

##Attributes

At 11:15, we transitioned to the need to review our standard set of attributes in Jamoma Max. Our starting point was an old set of notes on redmine. It does not look there is anything to eliminate in the list, but consensus was that several things could be clarified through re-naming.

General themes that drove individual decisions:

• favor convention over configuration
• the syntax should be simpler
• the mixture of slashes and colons in absolute addresses creates confusion

The following summary of our discussion was recorded by Trond:

@type 						stays

@ramp/drive					<extended discussion>
@ramp/function

@repetitions/filter			<discussion without decisions>

@range/bounds				=> bounds
@range/clipmode          	=> clipmode

@description				stays

@value/stepsize				=> stepsize
@value/default				=> default
@value						stays

@dataspace					<extended discussion>
@dataspace/unit				=> unit
@dataspace/unit_internal	(defaults to unit)

Current ambiguities:		midi(time) => midinote 
							midi(gain) => midigain
                        
@priority					stays

For ramp:

• Would "@ramp 1" is a possible simplification of "@ramp/drive"? No agreements.
• Should default behavior for decimal be ramp-enabled? What about for integer and for array?
• General feeling that "ease" would be a better name than "ramp" because of its connections. We would then look at expanding functions to include things Penner equations.

For dataspace:

• We agreed to make an implicit declaration of the dataspace depending on the unit used. We then need to make sure that all unit names are unique, as there is currently some overlap between midi and gain (see note above about midi time & gain).
• If possible, the proposal would be to have the dataspace only change at the object instantiation. This would mean it would be impossible to send something in Hz after you have set a dataspace to gain.
• We would need the ability to set the unit_internal used for calculations separately from the unit that is input and output.

Other notes:

• repetitions/filter - There is a general feeling that this is too long, but we have no good alternatives at present.
• accessing attributes of attributes - We need to have it working for 0.6, but we can create a more elegant interaction after 0.6.

##Morning Wrap-up

With 10 minutes remaining, we made a quick review of agenda items and found that we have touched on most things. We agreed that our discussion of the OSC query proposal will need a larger block of time than we will have available today.

Discussion was adjourned at 12:00, but we may resume later at 15:00.