Contributing to Galaxy Dannon Baker Introductions
● Who you are
● Dev experience
● What you’re interested in specific to Galaxy
● What you’d like to learn from this workshop Overview
● Why contribute?
● How to contribute code
● Contributing without coding Why Contribute?
● Galaxy core team is a small group with big goals ○ We have to prioritize our development efforts
● We have experience with usegalaxy.org ○ Which is completely unlike almost all other Galaxy instances
● You want things Divergence
Image: Kevin Pluck https://commons.wikimedia.org/wiki/File:Lion_waiting_in_Namibia.jpg
I was warned to avoid biological analogies
Image: Kenny Louie https://commons.wikimedia.org/wiki/File:Kitten_in_Rizal_Park,_Manila.jpg Divergence - This is not fun So you want to be a Hero (contributor)
1. Awesome.
2. Think about: ● Security ● Performance ● General Applicability ● Communicate Early and Often ○ GitHub ○ galaxy-dev ○ IRC Using GitHub For R&D The Roadmap
(https://github.com/galaxyproject/galaxy/issues/1928) HOWTO in a nutshell
Fork it.
Tweak it.
Test it.
Pull it. Writing code that's easy to integrate
globals() ● Readable .update({ "______": lambda x: globals() ● Commented .update(( dict([[x] *2])))}), ______((( ● Detailed commit "Just"))) ,______(( "another" messages )),______("Python" ● Preserves existing ),______( "Hacker") ];print ( " ".join( functionality [(Just),( (another) ),(Python ),Hacker] ○ Config conditional! ));______● Includes unit and/or functional tests credit: http://c2.com/cgi/wiki?ObfuscatedPython Python Style - A foolish consistency is the hobgoblin of little minds
Galaxy mostly follows PEP8, but readability is the ultimate goal ● Comment lines should be under 79 characters, code lines can be up to 200 characters ● Docstrings need to be reStructured Text and Sphinx markup compatible ● Whitespace: whatever is most readable, both for blank lines and space around operators. No tabs, use 4 spaces. ● thisIsNotJava underscores_strongly_preferred ● Avoid from module import * ● tox -e py27-lint JavaScript style
● Follow JSHint whenever possible, deviating for readability. ● Use semicolons to terminate statements. ● Put delimiters that open blocks on the current line; put delimiters that close blocks on their own line. E.g. if (condition) { do_action(); } ● camelCasePlease and capitalize ClassNames ● variables with jQuery objects should start with '$' ● JSDoc-style commenting http://en.wikipedia.org/wiki/JSDoc Writing code that is easy to reject
● Code that negatively impacts existing functionality to solve your specific case ● Suboptimal implementations that inhibit comprehensive work in the future ● Code that’s overly complex or difficult to parse (favor simplicity!) ● Tools (galaxyproject/galaxy) Writing Pull Requests that are easy to integrate ● Informative pull request message ● Context ○ New functionality: test cases ○ Bug fixes: how to reproduce ● Links to GitHub issues as applicable ● Tag specific individuals as reviewers @dannon, @whoever A Great Example (https://github.com/galaxyproject/galaxy/pull/2559) Tests and Demo code Tests and Demo code Working on the client?
Prior to commit/PR: make client
Two handy commands: grunt watch --develop node_modules/webpack/bin/webpack.js --watch Review Procedure
(https://github.com/galaxyproject/galaxy/blob/dev/doc/source/project/organization.rst#handling-pull-requests) Work in Progress [WIP]
● Marking a PR as [WIP] is a great way to get feedback early, and maybe even solicit help
● Will not be merged until WIP is removed Branches, targets, and [TAGS]
● dev ○ Generally your primary target for new features
● release_YYMM
● master @galaxybot test this The magic of forks and branching - collaboration via PR on PR
Someone might propose changes to your pull request with, instead of words, more code!
Example:
(https://github.com/BalthazarPavot/galaxy/pull/1) Conflict resolution
- Rebase - love/hate relationship w/ team members, easy to over use. - Squashing can make review more difficult
- Style - Don’t worry about this; trivial for the committer to handle at merge time.
Now we can do this! Contributing without Coding
● Mailing List (galaxy-dev) ○ wiki.galaxyproject.org/MailingLists
● GitHub issue voting/commentary ○ github.com/galaxyproject/galaxy/issues
● Wiki ○ wiki.galaxyproject.org
● Pull Request Review ○ github.com/galaxyproject/galaxy/issues Using GitHub For Friendly Coercion
Vote! Comment! Make your impassioned plea! Make sure we know what matters to you! Reviewing Pull Requests
● Yes, please! ● Consider the utility of the PR ○ Is this something that, included in Galaxy, would benefit the community at large? ● Pull the code ● Test, look for corner cases ● Errors or Improvements? ● Comment ● Approve! Wrapping Up
● Small team, large and diverse community
● Pull requests take time to review (help us!)
● Tell us how we can improve the process