Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code review committee #11

Open
4 tasks
syphax-bouazzouni opened this issue Dec 16, 2022 · 2 comments
Open
4 tasks

Code review committee #11

syphax-bouazzouni opened this issue Dec 16, 2022 · 2 comments

Comments

@syphax-bouazzouni
Copy link
Contributor

The Goal

Having the committee and process set up allows us to consider issues in a way everyone has agreed is fair, so people don’t feel like we’re just making it up as we go along.

Propositions

  • Define a default practice of the number of people to review any code submission and, who is required for what (A)
  • a list of any coding or other practices we expect to require on OntoPortal (B);
  • a group of people who serve as referees (C) for fundamental decisions about the acceptability of significant changes
  • Alternatively, designate a voter from each public portal. Not everyone has to vote on every issue; (D)
@graybeal
Copy link

Highly support this.

For the first item (A), I propose as a default that a one person from the following list should be required to review/approve OntoPortal code submissions, and that at least one other developer from any OntoPortal repository should be required to review/approve submissions.

  • Syphax; Jennifer; Misha; others as agreed by existing members. (Criteria are: wide experience with OntoPortal code; general awareness of agreed best practices, OntoPortal community software and active developments.)

I also suggest for the first item (A), or a separate item, that resolution of other tickets (not involving code or configuration changes) should also be reviewed by at least one technical leader (Tim, Clement, John, …), as well as one other person with knowledge of the specific domain. But review by the same person as already indicated would be OK too.

For item C (which I think is more about evaluating whether the addition of the feature makes OntoPortal better from the community or not as good for the community): I think this group should include one person chosen by each willing OntoPortal team to represent their team. Ideally it's either a PI (Mark or John, Clement, etc) or a senior developer or team leader (advised by the PI and rest of the team). Ideally decisions require consensus or at least 75% of active voters. It's up to each team that wants to participate in this evaluation to designate the voting member. (This approach essentially incorporates the last bullet (D).)

As soon as the teams in (A) and (C) are established, anyone could bring a 'recommended practice' (B) forward for evaluation by creating a ticket, approvable by a vote of 75% of the members of (A) and (C).

@jonquet
Copy link
Contributor

jonquet commented Jan 2, 2023

I think a committee and the mechanisms in (A) and (C) are relevants if we do find the right balance between progress and decisions making. We also need a bit of flexibility considering the OntoPortal Alliance is based on volunteering and not each group would have a representative (or simply just time and/or motivation) for participating in committees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants