Tripal User's Meeting 2018/05/04

Meeting Date
Attendees

Stephen Ficklin, Shawna Spoor - WSU

Meg Staton, Abdullah Almsaeed, Ming Chen, Bradford Condon  - UTK

Ethy Cannon, ISU

Nic Herndon, UConn

Nathan Weeks, USDA-ARS

Scott Cain, GMOD

Malachy O’Connell, ISU

 

Agenda

  1. Anything anyone wants to bring up?  Any questions?

  2. Moving Forward: governance

    1. Issue started on GitHub here: https://github.com/tripal/tripal/issues/344

    2. Identification of driving principles for future Tripal development

      1. Basics:  FAIR, Open-source, free

      2. Future changes should be for the benefit of the Tripal community, not any one group.

      3. Improved quality of Tripal core and extension modules of the community

      4. Prioritized development plan the transcends the goals for who has the most funding.  

      5. Develop a contribution process (commit standards)

      6. Avoid feature bloat

      7. Encourage others to more actively participate by

        1. helping respond to issues

        2. testing pull requests

        3. offering suggested changes to Tripal core.

        4. Health vs Unhealthy open-source projects (https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951)

          Users = orange; Contributors = green; Committers: teal; Technical Committee:  blue.

    3. Leadership structures for open-source projects: https://opensource.guide/leadership-and-governance/#what-are-some-of-the-common-governance-structures-for-open-source-projects

      1. Benevolent Dictator for life (BDFL) http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel

      2. Meritocracy: those who demonstrate merit get formal decision making role.  Contributions are made by people not the groups they represent. http://oss-watch.ac.uk/resources/meritocraticgovernancemodel

      3. Liberal contribution:  those who do the most work get a more influential role (not based on historical involvement) https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951

    4. What do we want to avoid?

      1. One group, with the most funding, directing Tripal away from community needs.

      2. Bottlenecks in responding to users.

        1. Bottlenecks in accepting PRs

      3. Slow to adapt to changing technologies

      4. Dependence on one group for core changes.

 

thoughts:

  • Ethy:  There should be a keeper or keepers.  Concerned that "cruft" will get built up in the code.  With lots of people working on it in various directions there could be bloat.  A keeper of a vision may lock things down too tightly. Have a lead and give roles to others for certain areas.

    • e.g. lacey in Tv2 was the Views expert so it made sense to have issues go through her.

    • So it may make sense to have contributors become experts in certain areas.  

    • Area leads help decide what is appropriate for that area.

  • Bradford:  Have a blend of meritocracy with committers.  Adding major features can be controlled via a vote, provided they already follow set contributions guidelines.  He would like not every minor decision has to go through several people and requires a few weeks to get decisions made.

    • Contributors may not be writing code in core, they could be responding to the issue queue, or helping to write documentation.

  • Meg:  It's important give people "in the code" the power to do what they need to do. Higher-level decisions on steering should be in a committee.  Two types of folks represented: those who are not in the code, but contribute financially and making decisions for their own needs (PIs), those who code and are actively involved.

  • How to improve contributions

    • Meg: When writing grants if folks commit to support core development, including training their staff to contribute to issue queue.

      • Budget for training to help make their modules shareable.

    • Ethy: agreed the learning curve is very steep, because it takes a while to feel comfortable knowing if problems are issues with Tripal or personal understanding

    • Bradford:  how likely someone is to jump in and contribute if:

      • pull requests are being accepted

      • there is visible communication between others.

      • online rules.

      • BC- We respond to issues, kindly and punctually.  If there’s coding that needs to be done to resolve, we encourage user to try to submit themselves.  Offer to help them with their PR too. → training good contributors.

    • Meg:  work on our yearly hackathon.   We need new developers who need training.  

      • get some funds to help bring individuals to our yearly hackathon.

    • Ethy:  have a virtual training "hackathon" online to help folks get started.  For example "who wants to start a Tripal v3 field and let's work on it together"

    • Stephen:  how to include folks outside of North American time zones.  

      • Ethy suggested reaching out to these folks and see what they would suggest to help them feel more able to attend/contribute.

  • Action Items:

 

  • Complete the document for "Workflow for Contribution" containing acceptable guidelines for pull requests, what's the process is used to approve them.

  • Project committee:

    • Consists of coders and committers to help setup governance rules and develop the documents and manage the project

    • Pull request mergers.

    • Issue answerererers. (the ones who make sure all issues ARE answered ;-) )

    • Deadline for Contributions and decision making document:  July 1st. Governance document can follow.

      • Sooner we have a guiding document, sooner committers can start merging PRs that meet guidelines without having to funnell all decisions through BDFL.

      • Give a community comment period.

      • Specifically formalize how to contribute, who merges PRs, what PRs need to be to get merged, how to welcome contribution by our actions in Github, etc. by this deadline  

      • Broader topics of governance can wait to be decided by the formal committee

        • Try to make a start on things like what should be in core with the intent that it will be expanded upon and tweaked by the steering committee once formed?

  • Defining steering committee:

    • We need a set of guidelines to preserve long-term goals.

    • Should represent everyone.  Labs that use Tripal, people who contribute, etc.  

    • These are major directional decisions:  Meet once a quarter? Once a year? Could even just meet 1x at PAG….

    • Once issues are identified in terms of what Tripal needs to think about.  IE supporting new data types, Drupal 8…. We can assign committees. Now anyone who wants to write a grant, they can write it into their grant and take on a role on the committee.

    • Is this really any different than how we do our meetings at PAG?

      • Well now we’ve designated some people as responsible.

      • Formalized leadership role for users who aren’t necessarily coding…

    • We need to have a good representation

      • Roles (but don't actually label people see below):

        • Developer

        • “New community member?”

        • PIs

        • Biologist

        • Cyberinfrastructure

        • Technology specialist (Drupal, data management, etc).

      • Is categorizing people into roles bad?

      • Maybe instead we make part of the mission “we want to make sure each of these roles are presented:”.  SO instead, when we put out the call, we want people in all of these areas.

      • How many members?  How long will they serve?  Maybe the committee will decide these things when they meet.

        • 7 is the perfect number.  Also 10, 15. perfect.

    • First thing on the docket during the first meeting

      • Talk about the switch to D8 and how we will go about it.

      • Shawna is planned to start working on this in August.  Hard to get committee going before then. Maybe instead interim committee should be formed so we can discuss this issue before

    • Have an open committee meeting in August/September to discuss Drupal 8 and Tripal v4

Meeting Type
Users