lead minutes

[mfrazer]

What follows are minutes from the voice call that Meghan, Mia, Jack, and Brian had on 12 August. We're planning another call for next week sometime. We will keep these minutes open until that next meeting and invite the whole team to comment on them.

Need to establish a roadmap, but we're still in crunch mode, so in the meantime, want to set forth some guidelines for how the whole team can most productively behave in the meantime: - Assume action is better than inaction (in response to suggestion that some of us weren't sure if we should jump in) - Search existing issues before adding a new one in case it's already in the list - If you enter an issue, assign it to the most logical person. If you are assigned an issue, but can't work on it, assign it to the next most logical person or one of the leads. - If you are working on an issue, assign it to yourself, so everyone knows who's working on what and so we don't duplicate effort. - When you commit, please include the related issue number using the built-in GitHub syntax for linking commits to issues - If you're the one who solved an issue (added the code, text, whatever) you should _not_ be the one who closes the issue - In the spirit of the Collaborator's Bill of Rights (http://mith.umd.edu/offthetracks/recommendations/) all of the OWOT team members should feel empowered to write/blog/present, etc, about the project as well as take credit for the work that they have done. We have created an issue (#116) to track conferences so that we don't duplicate proposals. When deciding if a commit is ready to go to production, we would like to consider: - are we staying true to the original vision / tone of Serendip-o-matic? - are the design elements in line with pre-existing content? - have any recent changes affected the accessibility of the site? - a code review and reality-check functionality against the original vision - serendipity over utility We are still hammering out how to implement a sign-off process for pushing to live, but for now, use the "Please review this on dev for going live to prod" label to indicate that you have something ready to go so others can take a look and sign off. Next month's priorities: - [ ] more automated deploy process, @briancroxall is going to facilitate this, working with @rlskoeser and @rsanc77 and other CHNM staff - [ ] add text to Connect page regarding new inclusion of additional APIs - Brian - [ ] write -one-page document 'go live' checklist (started at https://github.com/chnm/serendipomatic/wiki/Serendip-o-matic-%27go-live%27-checklist ) - [ ] development priorities ( - more detail at https://github.com/chnm/serendipomatic/wiki/Wishlist-items-and-future-development-road-map#development-roadmap-up-to-the-end-of-summer-re-announcement - Zotero integration - Getting "save to" ironed out - Getting more of the library pulled into Serendip-o-matic or updating what we promise in text - masonry issues - adding masonry 're-arrange results' shuffle) - Mia - [ ] outreach priorities (promote CafePress, Zotero list, bookmarks) - Jack - [ ] add licenses information in additional places - Meghan - [ ] additional writing/promotional opportunities - Meghan - [ ] documentation - All - [ ] roadmap - PMs/Leads Brian is going to set up another call for the four of us. Feel free to comment here or just get in touch with us if you have questions or issues. @rpalin @fontnerd @JackDougherty @amrys @mfrazer @erose @scottkleinman @moltude @amandavisconti @mialondon @foundhistory

[briancroxall]

I'm wondering if we should create some labels that say, more or less, "Brian reviewed this" just so we know that an issue has been reviewed by X people when looking at the larger issues list. Thoughts?

[briancroxall]

Hmm. We seem to have hit our max for names that could be tagged in this issue. @moltude @amandavisconti @mialondon @foundhistory

[amandavisconti]

I like the reviewed-by idea. When you've finished an issue and marked it "Please review this on dev for going live to prod", should we be tagging our team leads, the whole team, or no one (and assume people are regularly looking for issues marked this way)? Maybe we add a "pleasereview" tag?

[rlskoeser]

I'm glad we're working out a plan for reviewing stuff and approving it for production, but I'm a little hazy on how it is going to actually work. We have a bunch of bug fixes and clean up in the code, along with some new features, along with various UI and wording changes that need review, and I can't figure out how and when to move it to production because they're all in the same branch. I wondered about trying to cherry-pick bug fixes and make a bugfix release, but I'm not sure how I'd do that with our current git repo, and if I did it would need to be tested to make sure I didn't break anything by cherry-picking certain commits.

It's making me wonder if we should revisit the idea of having separate develop and master branches, but I'm not sure if that really helps us much because we'll still have to figure out a time when the development branch is stable enough to make a new release...

[mialondon]

To answer @amandavisconti 's question - I think assigning it to the team lead (or a PM or another member of the team if you're the lead) might work?

@rlskoeser 's question is more difficult to answer - we might need to change how we're using github, particularly once this short phase of sorting things out has passed. If we have branches then at least it'd be easier to review master for a stable release. Or we could have two heroku instances, one that's updated automatically so people can see their changes in situ, and another that's used for QA before going live?

[mfrazer]

I agree on both fronts. @amandavisconti - assigning it is a good way to make sure it's seen, in case we're slacking on getting in here, but I am planning to check the label every morning.

@rlskoeser and @mialondon - The complexity of this is why we didn't work it out on the call. :) I think branching is something we should consider. I know that adds a layer of complexity to using GitHub, but there's a way to merge just specific commits back to master (or dev), right? So, if I'm working on something locally and it works, I can merge that commit to the dev branch for deploy to heroku and testing. Then if it works it gets merged up into master for the next deploy?

Just one thought. I think the two heroku instances could work, also.

[mialondon]

Perhaps we could try for a call about this the week of August 26th? By then hopefully most of the current issues will be resolved and we'll have a relatively neat master.

[rlskoeser]

I agree that having a dev and a qa instance might be useful - it should be pretty easy to set up another heroku instance, and I think should even be possible to have travis-ci conditionally deploy the appropriate branches to the appropriate heroku instance.

If we pull from the ideas of git flow (whether or not we want to deal with all the details), having master reflect the latest production code is valuable because if we ever need to make a short turn-around bugfix we can do it relative to master and then merge the fix into both master and develop. (Also, I like the idea that the github front page / default version of code/readmes/etc is current production stuff rather than dev.) The git flow model for releases might also be worth thinking about - when we're ready to move development code into production, we make a release branch based on that version of dev code, push it to a QA server where we can test and make any adjustments that are needed (independent of normal development work that could still be happening in dev), and then when we're happy with it we tag the release and merge any fixes/cleanup into both develop & master.

I understand if this still might be overkill for us and more complicated than we need, but I wonder if most people on the team wouldn't have to worry about this too much- basically, we get them to switch to a develop branch (whatever naming convention we use, maybe master is our develop) and then only a few of us need to worry about the release branching and tagging.

[briancroxall]

These are good issues to raise. Perhaps it can be part of the larger conversation about the deploy, which I'm going to try to corner @rlskoeser on sometime this week.

[mialondon]

I'm more than happy to follow @rlskoeser 's lead! @briancroxall , as co-located PM can you work with her to write really simple documentation for developers, particularly those who might not be familiar with all the features? (I'm assuming lots of potential DH developers were like me and never really got around to sussing out all it could do).