Rough notes from Developer Meeting sessions on Friday, 2012-02-10
The following notes for this session are sparse - randomly selective
Review of the Roadmap to 3.0 Development Priorities page on the wiki
Work on vocabulary and authority control
Chris P: need to inform that work to incorporate support for multiple languages
Software wizards
Talk with Chris and Nate about scripts used at the Walker
Hovering over a term in term completion - see its context in the tree
edit section on proposed additions for media handling
3rd bullet on thumbnails
to limit scope to cataloging record
At Berkeley, want to propose structured objects soon
Can't just do at Berkeley, consult with, even have help from App and UI
Perhaps do some remote paired programming
Challenges on funding and resources for work not Mellon grant funded
In principal, we can spend IMLS funds at Berkeley to work on these
Version 2.2 Place Authority at least should be far enough along
Makes sense that core dev team should be able to do reviews on contributions to core
Overhead on the project
Chris M and Yura can consult, give us feedback on approaches
but we can't ask tasks to them
Perfectly appropriate for the community to suggest substitutions, or reordering
of priorities on the development roadmap
Patrick gives Megan and Angela some idea of difficulty, time estimates
As more people know how to do more across the system, like Chris and Richard, Yura and Amy ...
More and more, Chris is going to be telling us where to go and how to do stuff
Chris will be working on restructuring of internal app code
UISpec stuff
Eliminating at least part of artificial distinction between procedures and authorities
Will help introduce hierarchy into objects, for example
Talk to Chris if you plan to do app work, because of these changes
Taking a contribution in
As an example for Place:
Chris:
I'm usually asked to integrate near the end of the sprint
That means that I'm busier at the end
Better opportunity to review early on
Would require payloads in XML and JSON
Changes to tests
Resources provided for running tests
Wiki page
On what we each need, in our layers, before reviewing a contribution
Things we want ready before we consider this
Yura:
Similar to Chris
UI is entry point for people to identify problems, new features
Even if issue isn't in the UI itself
That means that I'm busier at the end of the sprint
Better opportunity to review early on
Not much impact on code itself
Addition of some templates, message bundle, configuration file for that record
Presence of the 'fake' pseudo-app layer UISpecs and UISchemas in the 'test' directory
so can run UI app locally without any developer
Just requires grabbing it from the running app
Those are the same files that Chris needs, as well
UISpec, UISchema, dummy payloads (XML, JSON)
Code submission process with GitHub
GitHub will help with this
A true queue of pull requests
I submit a pull request, someone makes some changes, do I need to cancel and re-submit pull request?
Just merge into the branch
It's not like submitting a patch
More like a merge path between the branch the pull request was submitted from and the main branch in the repo
Can add in-line comments
If you're not happy as a reviewer, can close it and ask for rework and resubmission
We should let people know, especially outside of our immediate group, that it was received and some idea of when we might look at it
merging into a branch is work
We could treat it as a workflow, 'these six steps need to be checked off ...'
There is an ordering issue
The app can't accept anything that the services haven't committed
Functionality test in this contribution review?
My understanding, you start on the Talk list, wireframes, etc.
Different from actually using it.
Scripted test during QA
The stuff running on a server may have a lot of local extensions
In theory create another tenant
Start out by sticking into a sandbox tenancy, play with it a little on Nightly
What if the contributions aren't self contained? If they need contributions from the core, like special searching?
Will need to be raised early - an up-front thing
With the first several contributions, we'll be playing it by ear
Many contributions may be relatively low-risk
If Nightly is effectively where the core dev is going on, may need a second slice for contributions
for internal team to throw up contributions and do first QA
Contributing team has its own server
Assuming they can open up a server for that
First functionality - look at it in core tenant, or a sandbox tenant
Chris would also like to see performance logs, to ensure no fanout
Jesse: generic VM image in which to test out
Chris at Walker: how far out is it that I can give you a directory
If the core is going to own it, it needs to be a pull request with the changed files
on one, two, or three repositories on the collectionspace project
the mini-build could include some convenience targets to merge these files
back into a tree
queue of submitted contributions should be public
so everyone can see it
broader community won't care about pull requests, and instead
look at wireframes, schemas, etc.
announce on Talk list, put up on a wiki - doesn't matter where it is,
can link to it from email, some page
Use git to manage contributions
branch on own repo
If testing an in-process contribution
Will be a contrib area for things we don't own
What does a community contribution area look like?
May be another repo, within collectionspace the project
Or can just be a public repo (anywhere), "just fetch it from here"
Tension between seeing what's been contributed and having them all in one place
and not having a maintenance headache for the core team
If we had a community repo under collectionspace
can we break it down into sections?
Yura: organization concept, like collectionspace,
then repos within the organization, that have teams assigned
If a trusted organization, could all be in the collectionspace org
each in their own repos
Community repo might not need to be a branch of the core repo
Org:Cspace
UI
App
Services
Contrib
Org:CSpace-UCB
UI
App
Services
Contrib
Can't have partial pull requests; it's all or nothing.
And the file structures at some level, no matter how deeply nested, need to match
Contrib can be links to repos
Main master of forked repo won't have any contributions in there
In your best interests to keep it up to date with main collectionspace master
All the rest will be documented in the branch
If it's a heavyweight contribution, you could have a branch in each layer in your repo.
Create a GitHub project
Your master is kept synced with master on the collectionspace repo
On the contributors repo, there should be a feature branch
in ui, app, svcs
In the main collectionspace repo,
we create corresponding feature branches for each layer
Org:Cspace
UI
master
Place (forked from Org:Contributor's Place branch)
...
Org:Contributor
UI
master
Place
...
Retire feature branches once pulled fully into core and accepted
On the wiki
there's a contribs area
links to contributors project pages on GitHub
or instructions
Could tag place
Could later contribute an update to Place
Chris from Walker:
If minibuild were part of each tree
Could conceivably use submodule init
other things beyond services/app/UI layer change:
some free structure on this
import files
ETL template
Perl script to do data cleaning on AAT
etc.
Will evolve over time
Wiki page for contributions
Not by organization, necessarily
Each needs minimal metadata
Description
Institution
Contact info (probably at least email)
Version last tested with
Special system requirements, prerequisites, dependencies, install instructions
Tagging would be nice
Feedback comments go in the Comments on the page
- Patrick has an image of the whiteboard which can be attached to this page