[VOTE] DataLad project governance
Hi all, over the past weeks, some people in the DataLad community have worked together to compose a draft describing the (future) governance of the DataLad project. This draft can be found as a pull-request at https://hub.datalad.org/www/project.d.o/pulls/4 with commit https://hub.datalad.org/www/project.d.o/commit/e2676e7b8f09b3ab9b0d2e8f803f9... Although this document represents a consensus within the group of authors, it makes sense to subject it to the same community-approval process that it describes, specifically in `decisions.md`, section `Voting`: https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8... Therefore, I am calling a vote regarding the adoption of this text as the governance specification of the DataLad project. As described in https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8... *everyone* has a vote. Voting is done by replying to this message, on this mailing list, with `+1`, `+0`, `-0`, or `-1` in this subject line. Comments and suggestions can be included in the message body. Such comments must be included for votes that oppose the adoption process to go forward with the proposed text. Given the central role of project governance, I believe that an "unanimous consensus" is desirable. The proposed voting period for this type of approval is 120h (5 days). Thank you for voting! Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
+1 -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
+1 On 2024-12-16T13:45:32.000+01:00, Michael Hanke via Datalad-devel <datalad-devel@fz-juelich.de> wrote:
Hi all, over the past weeks, some people in the DataLad community have worked together to compose a draft describing the (future) governance of the DataLad project. This draft can be found as a pull-request at https://hub.datalad.org/www/project.d.o/pulls/4 with commit https://hub.datalad.org/www/project.d.o/commit/e2676e7b8f09b3ab9b0d2e8f803f9... Although this document represents a consensus within the group of authors, it makes sense to subject it to the same community-approval process that it describes, specifically in `decisions.md [http://decisions.md]`, section `Voting`: https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8... Therefore, I am calling a vote regarding the adoption of this text as the governance specification of the DataLad project. As described in https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8... *everyone* has a vote. Voting is done by replying to this message, on this mailing list, with `+1`, `+0`, `-0`, or `-1` in this subject line. Comments and suggestions can be included in the message body. Such comments must be included for votes that oppose the adoption process to go forward with the proposed text. Given the central role of project governance, I believe that an "unanimous consensus" is desirable. The proposed voting period for this type of approval is 120h (5 days). Thank you for voting! Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
+1 -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
+1 Chris On Tue, Dec 17, 2024 at 3:50 AM Michael Hanke via Datalad-devel < datalad-devel@fz-juelich.de> wrote:
+1
-- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
-- Dr. Andreas Knüpfer Head of Scientific Computing Core CASUS - Center for Advanced Systems Understanding, Görlitz Helmholtz-Zentrum Dresden-Rossendorf e.V. (HZDR) a.knuepfer@hzdr.de, +49 3581 - 375 23123
+1 -- Michał Szczepanik, PhD Psychoinformatics Group, INM-7 Forschungszentrum Jülich
In order to initiate a discussion about a new idea, they should send an email to the [development mailing list](../communication) or submit a
Hey all, I generally like this development. Thanks for putting in the effort, to everyone involved! Some things aren't quite clear to me, but also not critical blockers: First: patch implementing the idea to the issue tracker (or version-control system if they have commit access). I see some overlap between initiating a discussion about a new idea on the mailing list, and opening an issue for a new feature on the issue tracker, but without immediately making it a PR (something which isn't mentioned in that excerpt). Is the mailing list then preferred to propose new features, or should the preferred path still be the issue and PR trackers of each repository? I would think it is the latter, and the mailing list being meant for "higher-level ideas" like new projects and long-term directions, but I could also see someone getting confused when reading this document. Second:
The Chair [...] has the casting vote when the project fails to reach consensus.
However, in case of a tie between choices in the outcome of a vote,
and: the external PMC member is asked to select one of these options as the winner. Maybe I am misunderstanding, but to me this sounds like both the chair and the external PMC member are tie-breakers, which obviously wouldn't work if they disagree on how to break the tie. How is that meant to work? Kind regards Matthias -- --------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens --------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------
Hi, On Fri, Dec 20, 2024 at 12:02:23PM +0100, Matthias Riße wrote:
Some things aren't quite clear to me, but also not critical blockers:
Thank you for the thorough reading!
First:
In order to initiate a discussion about a new idea, they should send an email to the [development mailing list](../communication) or submit a patch implementing the idea to the issue tracker (or version-control system if they have commit access).
I see some overlap between initiating a discussion about a new idea on the mailing list, and opening an issue for a new feature on the issue tracker, but without immediately making it a PR (something which isn't mentioned in that excerpt). Is the mailing list then preferred to propose new features, or should the preferred path still be the issue and PR trackers of each repository?
I want to put upfront that I am not confident that we would want to be more specific in the governance docs. Personally, I would want to see the mailing list to become the central communication channel. I believe that it is often non-obvious to new (and even past) contributors, which place would be best to put a feature. Having the discussion on that happen in a central place and be archived should be both educational, and efficient. When we are talking about a new feature for some topical extension package and everything is clear, then a contribution can go there directly, of course. In this case no regulation could improve this, hence we should not regulate. Obviously, if a PR simply pops-up in a repo, nobody would reject it just because a person did not ask for advice before. Maybe others can chime in too, whether we want to encourage prior coordination more strongly.
Second:
The Chair [...] has the casting vote when the project fails to reach consensus.
and:
However, in case of a tie between choices in the outcome of a vote, the external PMC member is asked to select one of these options as the winner.
Maybe I am misunderstanding, but to me this sounds like both the chair and the external PMC member are tie-breakers, which obviously wouldn't work if they disagree on how to break the tie. How is that meant to work?
Thanks for catching that! I agree it makes no sense. From my POV it should say: If there is no external PMC member that can function as a tie breaker, the Chair [...] has the casting vote when the project fails to reach consensus. The proposed setup that is subject of this vote has a named external PMC member. Adding this conditional clause would remove the casting vote privilege from the PMC chair -- which would be me, if adopted. I can say that I am OK with this change, and as a proposer of this text, I think we can go ahead and just make the change. Best, Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
+1 On Mon, Dec 16, 2024 at 4:45 AM Michael Hanke via Datalad-devel < datalad-devel@fz-juelich.de> wrote:
Hi all,
over the past weeks, some people in the DataLad community have worked together to compose a draft describing the (future) governance of the DataLad project. This draft can be found as a pull-request at
https://hub.datalad.org/www/project.d.o/pulls/4
with commit
https://hub.datalad.org/www/project.d.o/commit/e2676e7b8f09b3ab9b0d2e8f803f9...
Although this document represents a consensus within the group of authors, it makes sense to subject it to the same community-approval process that it describes, specifically in `decisions.md`, section `Voting`:
https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8...
Therefore, I am calling a vote regarding the adoption of this text as the governance specification of the DataLad project.
As described in
https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8...
*everyone* has a vote. Voting is done by replying to this message, on this mailing list, with `+1`, `+0`, `-0`, or `-1` in this subject line. Comments and suggestions can be included in the message body. Such comments must be included for votes that oppose the adoption process to go forward with the proposed text.
Given the central role of project governance, I believe that an "unanimous consensus" is desirable. The proposed voting period for this type of approval is 120h (5 days).
Thank you for voting!
Michael
-- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
Hi, On Mon, Dec 16, 2024 at 01:45:08PM +0100, Michael Hanke via Datalad-devel wrote: [...]
Therefore, I am calling a vote regarding the adoption of this text as the governance specification of the DataLad project.
As described in
https://hub.datalad.org/www/project.d.o/src/commit/e2676e7b8f09b3ab9b0d2e8f8...
*everyone* has a vote. Voting is done by replying to this message, on this mailing list, with `+1`, `+0`, `-0`, or `-1` in this subject line. Comments and suggestions can be included in the message body. Such comments must be included for votes that oppose the adoption process to go forward with the proposed text.
Given the central role of project governance, I believe that an "unanimous consensus" is desirable. The proposed voting period for this type of approval is 120h (5 days).
The voting period is over. No negative votes and 10+ positive votes have been posted. The governance specification has been accepted. A few minor disambiguities and copy-errors have been identified in the process. In order to simplify the process, I will address these in future changes and request a review here. Given the minor nature of these changes, I believe a lazy consensus will be sufficient for their adoption. Thanks to everyone that participated in this first and important vote! Best, Michael -- Michael Hanke GPG: 4096R/C073D2287FFB9E9B http://psychoinformatics.de
participants (8)
-
alexis＠praga.dev -
Andreas Knüpfer -
Chris Markiewicz -
Isaac To -
Matthias Riße -
Michael Hanke -
Michał Szczepanik -
Yaroslav Halchenko