Improving Transparency: Advisory Committee's Role and Community Involvement

Community Community Feedback
21

I want to emphasize that I'm not saying that non-code contributors are not contributors, but your statement illustrates the issue I'm talking about. The open source project is currently governed by an Advisory Committee with a single code contributor who have two major conflicts of interests(the "4.0" work and employment). I'm arguing the open source project need a model driven by code contributors, not that the entire ecosystem or community needs to be governed by developers.

Remember that most developers contributing are either doing it as charity/hobby or for the sake of their own users. Only one developer is employed and the rest do not actually need to listen to users if they don't want to(of course most of us are glad to listen!), ironically the employee has also spent most of their time on their own "4.0" project.

Inventing a more complex governance model and attempt to push developers or the open source project in particular directions will only harm the project even more.

22

@abbe98 You'll need to be careful and always distinguish using terms like "volunteers" or "volunteer developers" versus "hired developers". Instead of just "developers" lumped into one bucket. Thanks!

To be fair and accurate, @antonin_d was hired because of grants to help OpenRefine largely add a feature that many users have asked for, that of large dataset support and he's delivered that in my testing and kudos to him. That 4.0 project is not his own, but instead a contractual obligation back to our community and users. Does that make more sense?

What remains of the work todo (and money) are the other grants of which Reproducibility is at stake, but indeed there are murky waters there and even @antonin_d himself is not happy with that overall situation, but, it's a learning experience for all and a large part of the effort hasn't been wasted... it's just not fully realized yet, but there are plans to bring users mostly what they would prefer overall (that was realized through surveys, barcamp, and user interviews directly - which thankfully the team did that, so we'd know what is really worthwhile or not)

Totally agree that our governance will need to be simplified somewhat.
Things outside of the open source project (including IP - intellectual property) could actually be handled by the Advisory Council drafting some of those things in their own documents instead of the project governance. And instead only light mention in the project governence, like Godot does: Governance - Godot Engine

Advisors

The Board has enlisted the help of its most trusted and veteran contributors whom they call the advisors. The advisors are consulted on usage of funds as well as institutional matters. It is important to note, however, that while the advice of the advisory panel is weighed heavily, the final authority on these matters remains with the Board. In practice, the Board rarely makes an important decision without at least discussing it with the advisors first.

Like the Board, contributors do not apply to become advisors. Instead the process of joining the advisors group is organic; trusted contributors may be asked to join after showing dedication, expertise, and leadership within the Godot community.

23

I avoid those terms very intentional as motivation and intent matter, I for one is not a volunteer but my upstream work is definitively charity. Note that I do address developers by motivation rather than employment status (with the exception of C&S). Please consider your tone and perspectives other than your own. Thanks!

I assume it's a contractual obligation with C&S and the funder, it's definitely not with the community or the other developers(lot's previous discussions on the topic).

24

@abbe98 Oops, missed some words, good spotting.

  • a contractual obligation that brings benefits back to our community and users.
  1. The model within Godot's governance has a Board of Directors where it is balanced between community members (non-technical) and developers (technical). Do you think a balanced Board is a good thing for OpenRefine to embrace in its next draft of our governance?
  2. Do you think OpenRefine's next governance draft should mention the Advisory Council lightly similar to Godot's governance, especially where final authority on matters of usage of funds and institutional matters still rests with the board and not the advisors? What do you like or not like about Godot's governance "Advisors" section? Answering this would be very helpful.
  3. If you could highlight areas in Godot's governance which you like or dislike, it would be very helpful to me in understanding more deeply where you stand on certain things because my hunch is that between us, we are choosing different words, but mentally are probably standing in the same shoes of agreement and don't realize it yet.
25

You are making an interesting distinction between the open source project driven by code contributors and the broader ecosystem/community. I'm interested in exploring this further, particularly because OpenRefine is part of a much larger ecosystem, including reconciliation services, extensions, libraries, and users integrating OpenRefine into their operations.

  1. Where do we draw the line between these two groups?
  2. How is the open source part of the project governed?
  3. Who are the code contributors? Do we include developers, designers, and technical writers, grant Principal Investigator?
  4. Does the Advisory Committee and CS&S represent the project or the community?

Actually, it's the opposite. Antonin was already the project maintainer before the EOSS applications. The grants for reproducibility, EOSS-1 and EOSS-5, were written by Antonin. The Advisory Committee at the time (Thad, Antonin, and myself) approved the grant application to go through CS&S because we saw it as an opportunity to secure his position with the project while adding long-requested features. We had a similar process for our other successful grants (NFDI and Wikimedia-related), where the grant Principal Investigator reached out to the Advisory Committee to operate the grant via CS&S. The last round of unsuccessful applications (EOSS-6, Mozilla Infrastructure, and DEF) was my initiative. I realized that I should have consulted better with the community before taking those initiatives.

As we are fundraising to cover 2025 (OpenRefine 2024 Barcamp: Presentation of OpenRefine status), the advisory committee and I have allocated funds for a part-time developer to support the developer community as outlined in Grant opportunity: Open Technology Fund - #5 by Martin. This person will not be responsible for delivering new major features or making architectural changes. So far, we have received limited feedback on this plan from other contributors. We plan to move forward with it, as we believe that having a dedicated resource to maintain the project is crucial.

Looking at what made previous grants successful, I believe the application should come from the community, and the Advisory Committee/CS&S should provide the structure to administer them. If CS&S is not the best place to run the grant, it could be well executed via another organization.

During the BarCamp, we discussed the idea of creating community goal posts to identify contributors and users who are interested and to pool resources such as time, funds (via grants), and expertise. I am very enthusiastic about implementing this idea.

@thadguidry I would be cautious using Godot as an example, since they have a larger community (7,500+ contributors on GitHub vs 350 for OpenRefine) and their governance addresses different challenges (for example they left their fiscal sponsor)

26

@Martin I don't think the size difference matters, instead, I think we share the same governance challenges. I like that their board is made up of 50% users and 50% developers and that it's that whole group of folks that decide on how to spend money, rather than just... 2 people for us, or is it 3?...anyways I'd prefer having more users on a board and where the advisory committee is limited in capacity as Godot does. I just think that makes a lot of sense and brings more meritocracy instead of less.

27

I fail to see how this is the opposite of my understanding, there is no contract with the "community" but instead with individuals on the AC. Once again illustrating my initial points.

28

Here is a tentative draft for the new governance: 2024 - Governance update - Google Docs, taking into consideration feedback and discussions over the last few months.

I organized the document into three sections:

  • About this document presents how I approached the governance update and serves as a quick summary of the proposed changes.
  • Governance is a draft of a new governance document. This is where I need your opinion.
  • Working Group Suggestions are examples of potential working groups. At this point, those are only illustrative, and I am not expecting much feedback on them.

I will work to socialize its content and gather more feedback in the coming days, specifically during this week's Advisory Committee meeting (on August 29) and the next call with CS&S (on September 5). You can provide feedback by directly commenting on the document, answering this thread, emailing me at martin@openrefine.org, or scheduling a call from this page. I may also organize office hours for those who want to drop in.

Thanks

29

Thanks Martin. I like the return to an Apache style governance system. I'll try to review in more detail in the next few days, but since you said there was a meeting Aug. 29, I wanted to provide some initial feedback. Apologies for the brevity.

  • I know it's just a draft, but I hope it can continue to be streamlined and simplified
  • committer vs contributor has a very specific definition on Github. Committers have the ability to approve and merge pull requests. Contributors can do a wide variety of tasks including opening pull requests (code or documentation), translation, peer support, issue triage, marketing, etc
  • the draft seems to conflate recognition of contributors (which is a nice thing) with granting privileges to them (which is a necessary thing)
  • voting should be amongst the members of the group being joined, so no techies voting on membership in the marketing committee or vice versa.
  • two merged PRs is too low a bar for being granted commit privileges. The committers should decide what the bar is, but I think it'll be more like "demonstrated technical ability and willingness to follow team guidelines." Some developers might meet this bar immediately, while others might take some time to be ready.
  • the concept of "working group" seems fuzzy to me. Some of the things listed seem like individual roles (e.g. release manager) rather than groups and others should be open to anyone who wants to pitch in without any barriers to entry (e.g. peer support)
  • issue triage doesn't need to be done by developers. It would be a great way for someone who's familiar with the product, but not necessarily technical, to contribute. It would be nice to have enough help here that we could set a goal like "all issues will be acknowledged/triaged within N days" where N is TBD.
  • requiring forum moderators to transfer issues to Github introduces a bottleneck and doesn't scale. The users should do this themselves and we should have the necessary supporting documentation in place to make it straightforward for them to do this.
  • I think we currently accept translations from anyone. We could make this more restrictive, but I don't think we've had any issues so far.
    I think it's a great beginning and I hope others will offer feedback on it.

Tom

30

During this week Advisory Committee member we did a review of the document and provided the following changes

  • clarified the terminology around contributor and project member (see my answer to Tom below)
  • more details regarding restricted fund, including
    • a vote from the Advisory Committee before any application. With an expanded Advisory Committee, we should have a better representation of what the community wants to invest in. This process should help get a consensus on the scope before the work gets started.
    • Staff paid from a restricted grant must work first on the scope of that grant.
  • grammatical edit

Tom, thanks for the review.

The Advisory Committee provided similar feedback, and suggested the following changes which have been integrated in the document:

  • Contributor are anyone contributing to the project (what was called contributor-at-large and contributor in the initial document).
  • Project Members or Members are anyone who can vote a form working group (previously named contributor)

I suggest renaming the Core Developer group to Committer to stick with the @tfmorris definition above.

I agree. The "two PR merged" comes from this initial post and is up for discussion. In the proposed governance, it will be up to each working group to decide how to select its members and document it in their project charter.

I'm sorry if the document was unclear. I agree that anyone is welcome to contribute the way they want without being a project member or part of a working group. Working groups are a way for individuals doing a specific type of contribution to self-organize and take ownership of a part of the project. Creating a working group helps to (1) recognize regular contributors, (2) better structure the process around specific tasks, and (3) request funding.

31

I have very similar sentiments to @abbe98. I didn't dive into this conversation earlier because it occurred during @antonin_d 's vacation and it seemed to me that it would be better if he were present for it.

I believe strongly that approval of new committers should be done by the existing core committers as a group and not unilaterally by a single person or by virtue of employment status. Specifically, a new contractor or intern doesn't automatically get commit privileges.

I believe strongly that the core developers should follow development processes that they jointly agree upon. I think we're in a pretty good place for this (100% peer code review, etc), but will note that we are in extreme danger of falling below the critical mass of PR reviewers necessary to make this work. When Antonin was on vacation basically all work ground to a halt because there was no one to review my PRs.

My view of the size of the contributor community is much closer to Albin's 5 than @Martin 's 50. I would love to see more active contribution from those other 45 people, whether it be in the form of triaging issues, writing documentation, doing peer support, -- or just participating in these discussions.

Tom

32

This sounds like machinery in search of a purpose - creating a group of voters who can then vote on the creation of a working group who can then vote on members to join the group. Why not just "Hey, I'm going to work on UX stuff! Who wants to join me?"

I suspect perhaps the secret lies in the last item "request funding." Does that mean request funding from external sources in the name of the OpenRefine project? Or does it mean apply for funding from the OpenRefine coffers for some working group specific project?

Tom