Discussion: Future Tripal - Governance

[spficklin]

I'm starting this issue as a place for discussion about the creation of more formal rules to govern how we accept code into Tripal and how Tripal should look going forward. We have a really good opportunity with Tripal v4 and Drupal 8 to streamline development. I'm specifically leaving this vague to solicit thoughts regarding issues.

However I would like to add a few items do get the discussion going and please feel free to add your own.

1. What code should be included in "core" Tripal? Should we move some code out as extensions? (i.e. for Tripal v4/Drupal 8)
2. What protocol should we follow for pull requests? Do we establish quality standards, rules about who should accept pull requests and how do we resolve conflicts if there is a difference of opinion on a pull request.
3. Dorrie has suggested we form an advisory committee to provide high-level guidance to the Tripal community. What are your thoughts on that and what would that committee look like?

[bradfordcondon]

I read through some of the governance structures for open soruce projects and im wondering where you think Tripal falls. How many people do you imagine having write access? How many people have it right now and is that working?

I think having clear policies for PR standards is great. If we up our test coverage, we require tests to pass before merging at a minimum (right now it doesnt mean a whole lot). Either way, contribution guidelines would be a plus: https://help.github.com/articles/setting-guidelines-for-repository-contributors/

[spficklin]

Thanks for sharing those two docs @bradfordcondon. In regards to the first, I don't think a BDFL is the right model to go with. I suppose in the recent past, myself and @laceysanderson have been co-BDFLs, but mostly because we've been most active. Perhaps we need a guiding document that lays out our long-term wishes for Tripal and so long as we have like-minded individuals who can respect the document or make tweaks in an organized manner then I see no reason for a BDFL. Given recent conversations I've had with @laceysanderson, I'm not sure that any of those models work for us as written because contribution to Tripal comes from those groups most funded at any given point in time. So, we need something that protects the voice of unfunded sites and helps ensure funded sites have what they need at the core level to do what they need to do.

[bradfordcondon]

For the sake of argument, let me propose we're going to use the meritocracy structure, with an oversight committee, as a loose template.

I think that this will in fact meet our needs, because the PMC can be composed of groups who are not necessarily actively funded and contributing to Tripal.

This consists of

• Contributors
• Committers
• Users
• Project management Committee
• PMC Chair

The PMC is composed of PIs who use tripal. It is their duty to steer Tripal long term, and make it fulfill its mission of providing open source genomics website tools to community databases (and whatever else falls under mission statement).

Unfunded sites presumably fall under Users, PLUS they may sit on the project management committee. That is, until they are funded again, and they become contributors and committers again.

edit: obviously you dont need to be funded to contribute to Tripal. I'm operating under the implication of your concern, that sites that arent funded wont be pushing code and hterefore not participating in directing the project.

Funded sites consist of Contributors and committers. Once contributors are "trusted" in the community they can be committers, at which point they have write access to the repo and are merging PRs etc. I like this line:

The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before.

It's this shift to contributor to committer where we have to ask "when is someone trusted enough" etc...

So what do we get from organizing in a manner like this?

• The Tripal codebase moves forward faster. I think too much is asked of you personally Stephen, and formally passing both some of the oversight of Tripal into the PMC, but also the day-to-day code management to trusted members of the community, is downright essential.
• When we merge PRs, we have some standard checks IE travis to make sure it works. But we also have some sort of philosophy to ask "is this PR good for Tripal". And that philosophy is set via the PMC.
• Committers are held accountable to the PMC, ensuring the needs of all Tripal users are met.

edit: counterpoint.... PMC members are expected to be reviewing code changes. I wasn't really thinking in those terms... :|

[mestato]

I was going to comment on the PMC and committing decisions. Not to make this too complicated but I think we really need two separate things here.

Advisory/Steering Board - long term view, funding, overall plan of development - you know, the philosophical debates - composed of PIs and any long term contributors/stakeholders

Committer group - people with their daily work lives in with the codebase and issue queue. Can review things quickly when needed (48-72 hours) and have a strong grasp of the contribution guidelines. Can quickly test things. This is needed as a "group" to updated contribution guidelines, approve new committers, etc. Should probably all be on the above board as well.

[laceysanderson]

My priorities:

1. Protect the voice of unfunded sites, keep Tripal generic and lead us not into temptation of feature bloat
2. Help everyone feel welcome to contribute (comments, feature requests, bug reports, PR's all count in my books -you can be a contributor without ever writing a line of code!)
3. Ensure lots of communication without a lot of meetings ;-)

With that focus in mind:

• The meritocracy structure could be a good model for helping everyone feel welcome as long as the rules deciding levels of merit are clear and inclusive. We need to be careful not to downplay the value of bug reports & comments!
• Regardless of committee structure, I think we should focus on communication through github. This allows even those who can't make meetings (either due to time conflicts or funding constraints) to contribute. Furthermore, meetings can often be a productivity black hole ;-)
• I think a set of standards for what should go into core and how to accept PRs is arguably the only way to accomplish Priority 1. If we go with an advisory/oversight committee we need to ensure these rules are followed regardless of what the majority wants.

Draft Guidelines for encouraging open communication:

• Every bug should be reported as a github issue. Even if a bug is found by a committer who intends to fix it themselves immediately, they should create an issue and assign it to themselves to show their intent.
• Every feature request should start as an issue and discussion encouraged :-) The first step should be to compare it to our guidelines for what should be included in core. This needs to be a streamlined, inclusive process without encouraging feature bloat :-)
• Every task related to Tripal should be in github, either as it's own issue or grouped with like tasks into a single issue. This effectively puts our todo list on github making it transparent to anyone who wants to help. It has the benefit of showing how active our community is, keeps everyone informed with where Tripal is headed and makes it easy for others to chime in with experience, comments and support.

Concerns: How do we encourage communication without slowing down the process of development? What should we do if no discussion is forth coming? or if there are disagreements?

[bradfordcondon]

@almasaeed2010 has brought to my attention that we want to consider the liberal contribution model, because it doesnt require voting on everything.

Maybe we want a hybrid where PRs implementing new features trigger a vote, other PRs are handled by committers without requiring vote/consensus. Really we want (IMO) faster fixes, responsibility distributed a little more among committers.

i'm siding with @mestato that we will need some separation of PMC with technical expertise, and broader stakeholder group. It doesnt seem like it would make sense to bring in the stakeholders on highly technical decisions such as what is included in core vs module for example.

[bradfordcondon]

Summary of Slack discussion after meeting.

• Google document for contribution guidelines.
• Document will cover community guidelines (How do we conduct our disussions and turn problems into new code, encourage community enagagement, etc) contribution guidelines (Will this PR be accepted?)
• Governance for another day.
• Said document will allow new people to have write access to repo: they'll have rules to follow so they can make decisions about PRs without having to go through BDFL.

Contribution guidelines

• While Tripal is small, PMC === contributors.
• PMC must vote on any PR that adds new features for now. This is to combat bloat.
• Otherwise committers can merge if PR meets guidelines.
• Encourage users/contributors to test PRs.
• a PR must be tested by 2 people other than the submitter. (IE a contributor can test a PR to speed it along!)
  • one of those two people must be a committer.
  • This is also Drupal's way? @laceysanderson says "Drupal goes the route of, nothing gets merged in unless it's been tested by more then one person. I know personally this makes me jump in with reviews on Drupal.org whenever I see something I need b/c I know, otherwise it won't get in!"

[bradfordcondon]

Some questions/ideas:

• Knowpulse encourages use of boards. Do we want to mention them in our documentation? I use them to great effect in my personal projects.
  • For us I'm thinking no... but maybe it can be part of how PMC and/or steering committee gets things done and/or how steering committee confirms that people are working on the stuff that we want them to be.
• Should branches follow git checkout -b [issue number]-[short description] ? I dont do this because im lazy :|
• Other things we want to adopt from knowpulse? I like it especially as a github tutorial... but also want to keep document clean and simple where possible.

[laceysanderson]

• Boards: I agree on keeping them out of our documentation. Clean, simple and as few new technologies/apps as possible should be our goal to lower the barriers for contributors
• Branch naming: I think this one is worth the extra effort but can be worded as a suggestion/recommendation rather then a rule
• Tutorial: I think this should be kept separate from the how to contribute doc but perhaps referenced. That way the doc stays clean and easy to digest but anyone needing the extra guidance has it :-)

[laceysanderson]

Points for further discussion:

• voting for new features: do we want this to be by majority? should it require participation by both the advisory/steering committee and the project management team (trusted committers)?
• should we require a feature request be open for a certain period of time to provide the opportunity for discussion? if so, how long?
• more guidelines for bug reports...
• guidelines on moving an issue from one repo to another (bug or feature request that belongs elsewhere)
• further flesh out our "general project management"
• anything we're missing?

In reference to "Code of Conduct", I think we should flesh this out more on a second iteration, perhaps starting another document with a draft. Hopefully the admonishment to "be kind" (combined with the awesome links) is enough at this point.

[bradfordcondon]

do we want this to be by majority?

Ehhhh i'm torn. I actually think a single "No" should be grounds for something.

should it require participation by both the advisory/steering committee and the project management team (trusted committers)?

I think no, not by default. The PMC can decide to pass a request to the advisory committee for discussion if its not an easy decision/ a large decision.

should we require a feature request be open for a certain period of time to provide the opportunity for discussion? if so, how long?

100% yes. I think your 2 weeks is kind of long. What if we say 1 week, after an issue is tagged as a feature request. Then we make sure that all community members are aware that feature requests are important for discussion. Maybe we could even set up some sort of auto-notification, auto-doodle poll creation using existing if this then that style APIs.....

guidelines on moving an issue from one repo to another (bug or feature request that belongs elsewhere)

I'll take a stab at it. My general rule is: create issue in appropriate place, close the inappropriate issue, with links in BOTH places.

Hopefully the admonishment to "be kind" (combined with the awesome links) is enough at this point.

Agreed

[bradfordcondon]

We have a draft!!!!
Everybody! Give us comments! We'd like to leave discussion open for at least 48 hours (although obviously it wont be set in stone). After that we can formalize the committers/project management committee and start dealing with PRs according to these guidelines!!!!!

edit heres the draft

[ekcannon]

While it makes sense to have an advisory committee, I'm uncomfortable with the concept of a project management committee. There's a risk of Tripal becoming a design-by-committee hodge-podge if it lacks a [benevolent] leader who can say no and maintain a broad vision, across communities and into the future. Note that an effective lead listens to developers and the user community!

An alternative could be a sort of lead-lead who would mainly oversee the core development, and weigh in on module development as needed, with sub-leads on each module, with likely one person leading multiple modules. This is pretty much the model we have now and seems to be working.

Who this lead, or leads would be is an open question. Stephen and Lacey seem the most likely candidates for lead-lead (or co-lead-leads).

It probably goes without saying, that the lead(s) shouldn't be the only ones permitted to approve pull requests as this could create development bottlenecks, but it should be up to the lead(s) who has permission to contribute directly to the codebase and/or approve pull requests.

[laceysanderson]

I agree with @ekcannon to a certain extent. I think having someone(s) with a wider vision who can step in if the committee gets too carried away with exciting new features is a must. It's too easy to decide that because we all need something it should be in core which is a mindset eventually leading to bloat and maintainability issues.

That said, I am Very For a Project Management Committee (PMC) since it distributes much of the day-to-day management making for faster bug fixes and response to issues <3

As long as we have good guidelines in place for the PMC and trust the members of it to follow the guidelines I don't think there's a conflict between these two models. Especially if the lead-lead is on the PMC.

[bradfordcondon]

@ekcannon thank you for the feedback, I really wanted some more input. I would prefer if everyone who uses Tripal is excited about this organizational shift so I really want to discuss any and all concerns.

We have previously worked under a pseudo-benevelent/leads dictator model, where all major design decisions went through either lacey, stephen, or both. This meant if neither was around, PRs would not get merged.

It probably goes without saying, that the lead(s) shouldn't be the only ones permitted to approve pull requests as this could create development bottlenecks

The problem as I see it is, how do non-leads determine what PRs can be approved, and which clash with the vision of Tripal? The answer we've instated is contribution guidelines. Having these explicit guidelines benefits not just people trying to merge code, but people submitting it, too. Now I know if I want feature X, i need to create an issue first, and people will tell me if it fits the vision or not based on the guidelines. If I try to merge in code, at least 2 people are going to look at it and ensure it fits with the vision.

I wouldn't mind if we adopted a benevolent dictator/hybrid model, where "vision-related" decisions defer to lacey and stephen. I don't know if that would be better for Tripal, or better for them. I like that with a distributed model people can step away for a bit, and the project can keep moving. I believe that being more community structured will lead to more community engagement and contribution... but that might be naive idealism.

As long as we have good guidelines in place for the PMC and trust the members of it to follow the guidelines I don't think there's a conflict between these two models.

I like how you phrased this @laceysanderson and its my belief. But is there more we can/should do to ensure that the PMC doesn't fall into the trap ethy describes. @ekcannon are there issues beyond feature bloat that you have in mind?

[ekcannon]

A comment on project management in general: I've watched, and participated in a number of different governance models. The two that have fared the worst are:

1. The core team. A group of leads makes all the decisions, then doles out tasks to the rest of the team. Information passed on to team members tends to be incomplete, and the decision makers are unaware of the details of the various parts of the project and are prone to making bad and/or difficult-to-implement decisions.

2. Design by committee. Members tend to be polite and reluctant to turn down suggestions, and so, the project ends up with a serious case of feature-creep and loses integrity. It's difficult, but not impossible, for a team to maintain a common, consistent vision. OR, the members argue at length and nothing gets done. (Not likely with this community!)

The model that has worked best for me, both as a project lead and as a team member, has been a project lead with sub-leads on each task. Additionally, depending on the size of the team the lead (and maybe sub-leads as well) often appoints a "lieutenant". In the case of an open source project, the lieutenant(s) would review pull requests.

Because of past very bad experiences with structures 1 and 2 above, I get anxious when one or the other appears to be emerging, so wanted to raise concerns now rather than wait to see how things pan out.

[mestato]

I can see Ethy's point, about having a central "keeper of the vision", and if that doesn't conflict with a PMC thats ok with me. Because I think Tripal has gotten big enough and our leads are busy enough that a PMC makes sense, even if it is a bit of a "design by committee" system. With a project that is growing at the rate of Tripal, we need central leadership that is responsive to requests from many angles (PRs, issues, new groups contacting via email, training, etc), and Stephen and Lacey both seem very receptive to getting some help with managing all that. A person on the PMC is going to feel invested and like their opinion holds weight, so they will support the community through these types of activities. Developers who are disenfranchised from community decisions and don't see a path to change that aren't likely to jump in and help with other community support activities.

We are also trying to attract new groups to join Tripal or convert legacy dbs to Tripal, and I think having a defined community structure and a way to get core contributions at least considered in a timely manner is paramount. A decision to build a database on a certain platform has ramifications for 10-20 years (see all those old MODs!), so we need to have 10-20 year stability in mind that doesn't rely on one or two benevolent dictators wanting to do Tripal for that long. (Maybe Lacey and Stephen want to still be doing Tripal in 2033 but maybe they don't :).

And I want to say something about feature creep. As much as people are anti-feature creep in core, and I get that and its generally a good policy, much of the power of Tripal comes from having a suite of extension modules that actually do what you need them to do. If our extension developers don't understand core and don't update extension modules when core updates, then we're all in trouble. This is a somewhat tangential issue, but something I've been worrying about lately. And while PMC will probably stay very small, if some essential extension module developers are on there, it could be an important mechanism to keep the extension modules coordinated with core and have developers with enough knowledge of core able to update their modules quickly. I am not advocating pulling all extensions into core of course, but if they are consistently neglected in planning and writing major upgrades, existing dbs are stuck unable to upgrade to new versions of Tripal. This is something a larger PMC could at least consider and plan for.

[bradfordcondon]

I'm pinging this issue because as PAG approaches I think we wanted to revisit the Steering/Advisory committee. @mestato provided a nice summary:

Long term view, funding, overall plan of development - you know, the philosophical debates - composed of PIs and any long term contributors/stakeholders

I wonder if certain recent issues (ie the python API split) would be good issues for this group as well.

[ekcannon]

I'd say Tripal 4 is a pretty critical issue for the advisory committee to take up. I like Meg's summary.

[mestato]

I really don't love "oversight" as a committee name (a bit too brave new world), so I see two possible directions:

Board of directors - keeping the direct oversight idea (see for example Apache https://www.apache.org/foundation/governance/board.html)

Scientific Advisory board - more in NSF-style, where the relationship with the PMC is more collaborative/advisory

I vote SAB, any other opinions? Also, we need some guidelines and structure to at some point be formalized in the official CONTRIBUTING doc.

Some initial thoughts, starting from a point of being inclusive and emphasizing consensus building:

• Meetings: once per year (January, pre-hackathon with teleconference option?) and as needed other than that, can be called by PMC
• Director: elected by board at January meeting, responsible for calling votes, calling additional meetings if needed, and making sure meeting notes are posted and communicated to PMC
• Responsibilities: board members agree to serve for one year at a time, beginning by attend the yearly board meeting (in person or online) and to respond to issues in a timely manner when requested by the PMC or other board members. Their responsibility is to provide high level advice on steering Tripal which may relate to overall approach, development priorities, upgrade timelines, funding, etc. Issues will be available for full community discussion for x number of weeks prior to a vote
• Eligibility: anyone who has led a group who has published or maintained/updated a publicly available Tripal module within the past 2 years or has funding for Tripal development (core or extension)
• Election: anyone who is eligible and willing is welcome
• Terms: indefinite since its all volunteer based
• Decision making: Consensus based, vote called when needed by director, all objections recorded in meeting notes
• Agenda: items can be set by anyone on PMC or board
• PMC seat: at least one person from PMC has a seat on the board
• PMC issues: if PMC wants the board to weigh in on an issue outside the yearly meeting, they can request a meeting by notifying the director

[ekcannon]

If I understand Meg's proposal, and the gist of earlier discussions, the suggested governance is now:

1. A project management committee that approves (or nixes) new features. This could fit into my idea of co-lead-leads.
2. A scientific advisory board that looks to the future: development directions, technologies, new research needs, funding, et cetera.

I'm guessing that membership is not exclusive between the two (which would be bad). This makes sense to me.

How will a governance plan be accepted and adopted? Perhaps this should be a goal for the user meeting at PAG, to be able to announce and adopt a plan.

[laceysanderson]

I like the idea of accepting it via vote online (doodle poll with options agree/disagree) to ensure participation by everyone who wants to be involved (not just those at PAG). Then we can have our first meeting at PAG?

I like the scientific advisory board + PMC (project management committee) and agree with @ekcannon's summary although I consider the PMC a bit broader then just feature requests. The PMC is the first line of governance with the programming experience and Tripal familiarity to make informed decisions on "smaller" items such as feature requests and PRs.

I also like @mestato starting point for guidelines/structure :-) My main addition would be to eligibility:
anyone who has led a group who has published or maintained/updated a publicly available Tripal module within the past 2 years OR has funding for Tripal development (core or extension) OR anyone who has published/maintained a publicly available Tripal site.

[spficklin]

This topic was supposed to come up in our 11/13/2018 User's meeting. We ran out of time.

I also like Science Advisory Committee as a name. I agree with @mestato starting guidelines. Here's my suggestion to get started. How about we request volunteers to serve on the first Interim SAC and it will be the job of the SAC + PMC to set out the guidelines for the SAC. This way we get something started and we have a set of people responsible for finalizing the structure. Then once the guidelines and rules are in place we have the vote for the full SAC via a google poll. If we go this route we can have an SAC + PMC meeting at PAG sometime.

[spficklin]

I'm going to open a new issue for the advisory committee discussion. This thread has become a bit too long. After I do that are we safe to close out this issue? We have the Tv4 proof of concept and with my new issue for the advisory commitee I think those two things meet our two outstanding items.

[ekcannon]

This issue has been replaced with this one:
#786

[bradfordcondon]

Given theres been no additional discussion on PMC and day-to-day governance, I'll close this out.

Advisory committee discussion should continue in #786