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

33

I updated the section regarding how Core Developers (or core committer group, the name is not fixed yet) are elected to restrict voting to current Core Developers.

Regarding the creation of member who can vote: the creation of the members group is mostly to identify who can elect the Advisory and Code of Conduct committees. In my opinion, it is an essential part of supporting a transparent election process. It is also a formal way to recognize contributors and invite them to continue participating in the project.

Regarding working groups. I invite you to read the draft governance regarding the working group. In a nutshell, working groups are a way to distribute responsibility and authority within the project. Currently, the Advisory Committee is criticized for performing too many operational tasks that should not be within their scope. Working groups help move back operational decisions within the community.

Working group are self-organized and not elected, so the "machinery" described in your post does not exist. You only need three members completing a group charter to defined it scope and make it easy for the rest of the community to understand who they are and what they do. The working group helps addressing the two top feedbacks we received on the current governance:

  1. Improve transparency on how the project operates.
  2. Establish the foundation for creating contributor pathways and a handbook by officially assigning a group of contributors responsibility over a certain part of the project (translation, maintaining the documentation).

Regarding funding a working group can request a funding either from the unrestricted fund or by preparing a grant application for restricted fund. From a governance standpoint, it would be more logical for the group responsible for carrying out task X to be in charge of requesting and overseeing the associated budget. This way, funding requests and allocations no longer come from the Advisory Committee (which was a previous complaint) but from the community based on what it thinks is important to fund. The Advisory Committee will only approve the usage and assist in managing the funds (thus move back into a strategic role). For example:

  • An industry-specific group (GLAM, journalist, librarian) applies for a grant to improve particular aspects of OpenRefine relevant to their workflow
  • The support group asks for funds to create new introduction videos.
  • The Core Developer group can ask for a budget to hire a developer instead of the Advisory Committee since that group knows best what is needed.

Again, this does not prevent spontaneous contribution and discussion to any aspect of the project; it offers a structure to those who want to better coordinate efforts in a specific area.

34

To offer a different of ways to provide feedback, I have also scheduled three community calls in the upcoming weeks to discuss the governance document.

35

First: given that I am on my way out, I don't think my voice should count much in those decisions, as the governance model should work for people who stay involved in the project on the longer term.

I am interested in the discussion because I think the current way the project is organized isn't doing a good job at bringing new people in. But a new governance model can only help in that regard if it matches the way of working of people who remain active.

What I am hearing from @tfmorris and @abbe98 makes me wonder whether they see a need for integrating non-developers in the governance of the project at all. I think that's worth asking directly to clear any misunderstandings.

OpenRefine could adopt the Apache model, where you have committers and PMC (who are themselves committers with additional trust). The PMC would replace our advisory committee. And the rest are welcome to get involved ("hey, let's improve the UX") but don't have a formal role in the governance model.

I think the Apache model works well for a certain type of projects (the Apache HTTP server, Apache Spark, Hadoop, Jena…) where users are mostly programmers themselves. In this context, there isn't much harm in restricting the governance model to only include developers, because any user, designer, trainer, will likely also be one and so has access to the decision structures.

To me, OpenRefine is a different sort of project. It's a desktop application, which aims to serve users who don't identify as developers. So that's why I have been trying to include more profiles in the governance of the project. But it hasn't worked as well as I would have liked.

So, I think it's perhaps worth answering this question first: who do we think should have a say in project governance. And then we can figure out how to organize those people in teams / committees / what not.

36

I wanted to share here my notes from my call with @thadguidry and @Antoine2711 on October 2nd, 2024, as part of the community meetup call. Of the three calls scheduled, this was the only one with participants.

During the call, the discussion was mainly between @thadguidry and @Martin and focused on

1) The core developer group. @thadguidry presented a different perspective on the structure of the committer group (or core dev group) to limit its constituancy to one developer and a backup person. These are currently @antonin_d and @tfmorris. The group would keep the same responsibilities as those described in the draft governance.

Anyone in the community is free to comment on pull requests. @thadguidry suggested not providing clear guidelines on how to join this group and leaving it at the discretion of current group members. @Martin argued that this process is not transparent and potentially discourages potential contributors from getting involved. We would love to have other developers' perspectives on these points.

2) The draft governance document could better represent the relationship and dynamic between the different groups in a couple of sentences, similar to what Inskape does on its teams presentation page.

3) the structure of the community page on the website. The page currently mixes community aspects (getting support, contacting the project) and contributing. The recommendation is to split the content into two pages. Links for contributors should have a more explicit anchor to indicate they are redirected to the contributor guide.

We also made minor edits and suggestions directly in the Google Document.

37

As there is no new feedback on this proposition and we haven't reached any consensus, I will update the current governance to better reflect how the project currently operate:

  • Reintroduce Apache-style consensus
  • Documentation of the Core Committer / Developer group who can merge PR. Current members are @tfmorris and @antonin_d
  • Removal of the Steering Committee
  • Document the grant application process where we start a thread on the forum as soon as possible.

I will link the PR here once it is ready.

I also heard the request to open Advisory Committee call to the community. This is something I will discuss with the committee.

38

@antonin_d following your message here, I wanted to confirm with you that it is OK to add your name to the Core Committer / Developer group for now. We can specify in the governance doc that you will be leaving that group in spring 2025.

1 Like