Improving Transparency: Advisory Committee's Role and Community Involvement

[Martin]

@tfmorris

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 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.

@tfmorris

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?

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.