IMPORTANT: Gramps project governance

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

IMPORTANT: Gramps project governance

Nick Hall
Devs,

As a result of Paul's feedback, I have added an item to the v5.1 roadmap
to discuss our project governance.

https://gramps-project.org/wiki/index.php?title=5.1_Roadmap#Project_governance

At present, we use a benevolent dictator model.

Would you like to see this changed?  If so, what type of model would you
prefer?

Even if we decide to stay with our current model, it may be a good idea
to document our governance, procedures for submitting contributions and
conditions for their acceptance.

Let me know your opinions.

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

prculley
Since I started this with my comment, I'll chime in with some additional thoughts.

I would like to thank Nick and the other developers who have assisted my in coming up to speed on Gramps (and programming etc.).  It has been many years since I last did any significant programming, and this new hobby is a lot of fun and makes me feel useful as well.

I believe we do need a 'leader'.  And having a leader that has a long experience with our program is very valuable.  I also believe it is important to have someone who is a tie breaker if (when) conflicts develop.  And to remind us of the rules, help set directions, schedules etc.

I have watched while two other developers became frustrated with the current governance model and left our already small developers community.  And I have felt some of their frustration when, after a lot of work trying to deal with bugs or issues with the current GUI, my submissions are rejected with a "I don't like this".  I suspect that some of these frustrations are made worse by poor communications; it takes time to write good comments and we often don't have that time.

I also think that if we got a bit more rigorous with the PR as a method of making submissions, instead of just doing commits, it would allow for a better review with a comment stream and the thumbs up/down tagging to indicate if we are headed in the right direction.

I think we need some additional clarity on exactly who can commit a PR, and how soon.  At the moment, some minor PRs are quickly tested and commited by another developer, and other more significant PRs sometimes seem to languish for long periods waiting on the leader.  And some are commited by the submitter, sometimes very quickly.

I think it would be best if we did not put too much responsibility on the leader as well; we all have periods when we get busy doing other things, and it would be best if there was not a single bottleneck, which slows things down.

To this end I would suggest that we allow any developer to accept/commit a PR by another submitter, as long as a reasonable length of time had elapsed for review, and the reviews are generally positive.  If there were strong negative comments, they should include a 'why' and suggestions on how to improve, that were generally accepted and dealt with before accepting.

Enough for now, maybe this will get some comments going...

Paul C.

On Sun, Mar 25, 2018 at 10:31 AM, Nick Hall <[hidden email]> wrote:
Devs,

As a result of Paul's feedback, I have added an item to the v5.1 roadmap to discuss our project governance.

https://gramps-project.org/wiki/index.php?title=5.1_Roadmap#Project_governance

At present, we use a benevolent dictator model.

Would you like to see this changed?  If so, what type of model would you prefer?

Even if we decide to stay with our current model, it may be a good idea to document our governance, procedures for submitting contributions and conditions for their acceptance.

Let me know your opinions.

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
In reply to this post by Nick Hall
Devs,

I am replying to my own post because I never received Paul's reply - I
am reading it from the archive.

> I also think that if we got a bit more rigorous with the PR as a method of
> making submissions, instead of just doing commits, it would allow for a
> better review with a comment stream and the thumbs up/down tagging to
> indicate if we are headed in the right direction.

I totally agree.  In fact, I proposed this in a post back on 31 Dec 2016:

https://sourceforge.net/p/gramps/mailman/message/35577281/

Unfortunately, the proposal got no support back then, but opinions may
have changed.

I suggest the following:

* All contributions must be made by submitting a PR.  This includes me
and other administrators.
* A PR must be left open for a certain amount of time for review - 1 week?
* During this time any developer may raise an objection
* If there are no objections, then the PR is deemed to be accepted
* Any developer can merge an accepted PR after review and testing
* If there is an objection, then the developers concerned should try to
form a consensus after discussion
* If a consensus cannot be formed, then the PR is either rejected or
progresses to dispute resolution
* Anyone who has made a non-trivial contribution should be made a developer

The aim of this is to encourage new contributors and get more code reviewed.

> And I have felt some of their frustration when, after a lot of work trying
> to deal with bugs or issues with the current GUI, my submissions are
> rejected with a "I don't like this".

Creating a good user interface is difficult, and changes to the GUI are
often contentious.  In the past, changes were discussed on the list and
some agreement reached before coding.  Otherwise, writing a prototype is
not a bad idea, but be prepared for it to be rejected; this has happened
to me on more than one occasion.

If a PR is rejected, then it can be referred to dispute resolution and I
will make a decision.  However, when it is me that is saying "I don't
like this", then you have a problem.  If I object to a GUI change, it
will probably be for one of the reasons listed in our UI style guidelines:

https://gramps-project.org/wiki/index.php?title=UI_style

You can always ask me for a more detailed reason, and I am also happy to
review any past decisions.

Regards,


Nick.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Tim Lyons
Administrator
I originally objected to the requirement to always submit PRs, because of the
extra complexity and extra steps involved in doing this.

I also dislike PRs, because mostly the git version history seems not to be a
single straight line. New changes are often linked back to some earlier
commit (? as well as to the latest commit). When I mentioned this before,
one (non-regular) contributor said that is just how git works, but I
understand that it s possible to avoid this problem, but it is really hard!

In contrast, when I just submitted commits straight to the master, I pulled
the latest commit, made sure I was applying my change on top of that commit,
and then pushed the change. I could do this for the same change for several
versions of Gramps one after the other. (There was a tiny chance that
someone had made a commit between when I got the latest and when I pushed,
but the chance was tiny).

I suppose that as I am now a much less regular developer, my opinion may be
less relevant.

I don't think that your proposal is likely to "encourage new developers".



--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-Dev-f1791083.html

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

enno
Op 1-4-2018 om 02:26 schreef Tim Lyons:
> In contrast, when I just submitted commits straight to the master, I pulled
> the latest commit, made sure I was applying my change on top of that commit,
> and then pushed the change. I could do this for the same change for several
> versions of Gramps one after the other. (There was a tiny chance that
> someone had made a commit between when I got the latest and when I pushed,
> but the chance was tiny).
This is exactly what I do in the office, where I work in a small team,
where we all have push rights for the main repo. I use sourcetree there,
and I regularly use pull --rebase to retrieve the latest code from the
development branch, and when I try a push and a there was another push
by a fellow developer, sourcetree will tell me that I can't push, so I
do another pull --rebase, and then push again.

In my experience, this works quite well, and sometimes we even do a
forced push, when someone thinks that rewriting history is a good idea.
I'm not in favor of that, but it does work, as long as everyone knows
about it.

I'm not  a core developer for Gramps, but I do think that the core
developers should be trusted to do standard push, no forced push, and
for them, PRs are just an unwanted sort of bureaucracy. This is because,
when tests fail, Git offers more than enough means to correct.

Just my cents.

Regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

John Ralls-2


> On Apr 1, 2018, at 8:02 AM, Enno Borgsteede <[hidden email]> wrote:
>
> Op 1-4-2018 om 02:26 schreef Tim Lyons:
>> In contrast, when I just submitted commits straight to the master, I pulled
>> the latest commit, made sure I was applying my change on top of that commit,
>> and then pushed the change. I could do this for the same change for several
>> versions of Gramps one after the other. (There was a tiny chance that
>> someone had made a commit between when I got the latest and when I pushed,
>> but the chance was tiny).
> This is exactly what I do in the office, where I work in a small team, where we all have push rights for the main repo. I use sourcetree there, and I regularly use pull --rebase to retrieve the latest code from the development branch, and when I try a push and a there was another push by a fellow developer, sourcetree will tell me that I can't push, so I do another pull --rebase, and then push again.
>
> In my experience, this works quite well, and sometimes we even do a forced push, when someone thinks that rewriting history is a good idea. I'm not in favor of that, but it does work, as long as everyone knows about it.
>
> I'm not  a core developer for Gramps, but I do think that the core developers should be trusted to do standard push, no forced push, and for them, PRs are just an unwanted sort of bureaucracy. This is because, when tests fail, Git offers more than enough means to correct.

I don't know what this has to do with a requirement for PRs. Yes, if you do a straight merge then history can get a bit messy, and one must be careful that PRs are based on the right branch so that they don't wind up duplicating commits on both sides of the merge. Not a big deal and easy to see in GitHub: If the PR has commits from more than one author it's likely that it's crossing branches.

If we want to keep a linear history in the way of centralized VCSes then merging just requires a couple of extra steps, and it can't be done from Github's GUI. I've explained this before, but it's been a while so I'll recap:
* find the root commit for the feature branch and check out a PR branch at that point.
* pull the PR using the "command line" from Github.
* Rebase the PR branch onto the mainline branch. Resolve any conflicts, build, and test.
* If you want a merge commit to maintain traceability to the PR, pass --no-ff to git merge.
* Push.
* Note on the PR that it was merged after a rebase, thank the submitter, and close the PR.

If you want a merge commit and your push is rejected, *don't do a pull --rebase!* That will lose the merge commit. Instead, reset --hard HEAD^, pull, repeat the rebase of the PR branch and re-do the merge.

This is a useful technique for any set of commits that one wants to keep together and set apart in the graphical history  while keeping the commit stream linear: It allows you to have nice descriptive commit messages for each commit and then explain the intent of the whole branch in the merge commit, e.g. "Implements GEP 123". On the other hand it's a bit more work than clicking the "merge" button on the Github PR page. Whether it really makes the history easier to follow and is worth the effort is a matter of opinion.

Regards,
John Ralls



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

John Ralls-2
In reply to this post by Nick Hall


> On Mar 26, 2018, at 9:19 AM, Nick Hall <[hidden email]> wrote:
>
> Devs,
>
> I am replying to my own post because I never received Paul's reply - I am reading it from the archive.
>
>> I also think that if we got a bit more rigorous with the PR as a method of
>> making submissions, instead of just doing commits, it would allow for a
>> better review with a comment stream and the thumbs up/down tagging to
>> indicate if we are headed in the right direction.
>
> I totally agree.  In fact, I proposed this in a post back on 31 Dec 2016:
>
> https://sourceforge.net/p/gramps/mailman/message/35577281/
>
> Unfortunately, the proposal got no support back then, but opinions may have changed.
>
> I suggest the following:
>
> * All contributions must be made by submitting a PR.  This includes me and other administrators.
> * A PR must be left open for a certain amount of time for review - 1 week?
> * During this time any developer may raise an objection
> * If there are no objections, then the PR is deemed to be accepted
> * Any developer can merge an accepted PR after review and testing
> * If there is an objection, then the developers concerned should try to form a consensus after discussion
> * If a consensus cannot be formed, then the PR is either rejected or progresses to dispute resolution
> * Anyone who has made a non-trivial contribution should be made a developer
>
> The aim of this is to encourage new contributors and get more code reviewed.
>
>> And I have felt some of their frustration when, after a lot of work trying
>> to deal with bugs or issues with the current GUI, my submissions are
>> rejected with a "I don't like this".
>
> Creating a good user interface is difficult, and changes to the GUI are often contentious.  In the past, changes were discussed on the list and some agreement reached before coding.  Otherwise, writing a prototype is not a bad idea, but be prepared for it to be rejected; this has happened to me on more than one occasion.
>
> If a PR is rejected, then it can be referred to dispute resolution and I will make a decision.  However, when it is me that is saying "I don't like this", then you have a problem.  If I object to a GUI change, it will probably be for one of the reasons listed in our UI style guidelines:
>
> https://gramps-project.org/wiki/index.php?title=UI_style
>
> You can always ask me for a more detailed reason, and I am also happy to review any past decisions.

Nick,

While getting code reviewed is good, without a commitment to actually review every PR this becomes a pointless time waster. The importance of review rises with complexity, but defining complexity in a way useful to making a rule is hard.

I also think you want to set the bar for designating a developer a little higher, perhaps 3 non-trivial PRs or some amount of time consistently contributing. A one non-trivial PR rule means that every drive-by contributor gets added to the developer list. That will make it pretty unmanageable pretty quickly. All of which completely ignores the non-trivial matter of "what does non-trivial mean?".

Any really major change needs to be proposed and discussed before coding starts, because once a design is coded up the author has gotten pretty thoroughly committed to the design and is going to resist comments requiring a major rewrite unless the commenter can show serious flaws. I think we saw that two years ago with Doug Blank's DBAPI changes, and we're still dealing with the fallout from that.

Regards,
John Ralls





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
On 01/04/18 17:32, John Ralls wrote:
> While getting code reviewed is good, without a commitment to actually review every PR this becomes a pointless time waster. The importance of review rises with complexity, but defining complexity in a way useful to making a rule is hard.

The idea is to give everyone the opportunity to review code before it is
merged.  I already look at every PR submitted.

My suggestion will certainly introduce a delay, but I don't see it as a
waste of time.

If all changes are made using a PR, then we don't have to try to define
the complexity of a change.  We could exclude changes to certain
directories - debian, mac, windows and po for example?

>
> I also think you want to set the bar for designating a developer a little higher, perhaps 3 non-trivial PRs or some amount of time consistently contributing. A one non-trivial PR rule means that every drive-by contributor gets added to the developer list. That will make it pretty unmanageable pretty quickly. All of which completely ignores the non-trivial matter of "what does non-trivial mean?".

OK.  My main goal here was to make it easier for a contributor to become
a developer.  By trivial, I was thinking of something like correcting a
typo.

>
> Any really major change needs to be proposed and discussed before coding starts, because once a design is coded up the author has gotten pretty thoroughly committed to the design and is going to resist comments requiring a major rewrite unless the commenter can show serious flaws. I think we saw that two years ago with Doug Blank's DBAPI changes, and we're still dealing with the fallout from that.

Absolutely.  I cannot agree more.  Discussion in the mailing list and
writing a GEP, where appropriate, is essential.

Unfortunately, I didn't receive the reply from Tim or Enno, so I'll add
a couple of comments here.

I prefer a linear git history so I always merge manually.  I always
rebase the branch and do a --no-ff merge when there is more than one
commit.  A force push back to the fork prior to pushing to the main
repository will allow GitHub to automatically mark the PR as merged.

I would like to avoid treating new developers any differently to
established core developers.  Even experienced programmers can benefit
from a code review.

Where do we go from here?  I don't really mind what decision is made.  I
am happy adopting a new contribution policy or staying with the existing
one.

John, perhaps you, together with Paul and Tim could come up with a new
policy or just formalise the old one?

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Paul Franklin-5
I have decided to make some comments on this thread.

While I am not a developer at the moment, I was a developer
once and hope to be a developer again, if some things
change.  So making some comments on what I would like in the
way of "change" seems worth doing to me.

How my comments are received, and what if anything changes
will of course be up to all of you.

So first, let me say that I wish this thread was discussing
"project governance" instead of committing policy.

I feel that the governance of gramps should be discussed
first.  Once that is taken care of, and any new consensus is
reached, then a similar discussion should happen about
possible other changes, such as committing policy, branch
merging, etc.

That way, when the discussion of committing policy was over,
say, and everybody who wanted to comment had commented, any
decision would be made by the "project governance" system,
whatever that might be.  Rather than deciding everything
under the present "project governance" system.

Remember, Nick's original "roadmap" post asked "are there
any policy changes we wish to make?" and Paul said "I am
uncomfortable with having a single person with effectively
absolute veto power over changes, and who doesn't always
follow the rules set up for everyone.  I would prefer for
some sort of voting process for significant changes ..."

But then his next sentence was "And always use PRs for
significant changes, ..."  followed by some other committing
policy proposals, and then various "roadmap" gramps51
topics.

Then Nick replied, in part, by saying:

> Thanks for your reply.  I have incorporated your comments
> into a draft roadmap:
>
> https://gramps-project.org/wiki/index.php?title=5.1_Roadmap
>
> It would probably be best to discuss these topics in
> separate threads on the mailing list.

Note that the wiki page has a "policy changes" section,
which had three subsections: on project governance, branch
merging, and "pull requests for significant changes".

Then Nick started this thread, on project governance, with
these initial comments:

> At present, we use a benevolent dictator model.
>
> Would you like to see this changed?  If so, what type of
> model would you prefer?
>
> Even if we decide to stay with our current model, it may
> be a good idea to document our governance, procedures for
> submitting contributions and conditions for their
> acceptance.
>
> Let me know your opinions.

Paul made the first reply to this thread, and his comments
are there for you all to read so I won't quote them, but
point out that after he made some initial comments on
project governance, he then made some more comments on
committing policies.

While I certainly think a discussion on committing policies
could be useful, I think it is far more important to discuss
the gramps project governance.  As I said, I think if any
committing policy changes are made, they should only be made
after any project governance change happen.

Nick said "let me know your opinions" so let me first say
that I appreciate him posting the two links on the wiki's
roadmap page:

http://oss-watch.ac.uk/resources/governancemodels
https://opensource.guide/leadership-and-governance

I personally preferred reading the first one, and I will
also note that the second one had two links to the first
organization, which may indicate something, but you can read
them both for yourself.

In the first one, the "governance models" section starts off
by saying this:

"A governance model describes the roles that project
participants can take on and the process for decision making
within the project.  In addition, it describes the ground
rules for participation in the project and the processes for
communicating and sharing within the project team and
community."

A short time later it says:

"Governance models range from centralised control by a
single individual or organisation (benevolent dictatorship)
to distributed control awarded in recognition of
contributions (meritocracy). You can find governance models
at any point along this spectrum; it is also possible for a
project's chosen governance model to move along this
spectrum as the project matures."

Then goes on to say:

"It's interesting to note that a particular governance style
doesn't automatically imply a particular contribution model,
although projects do tend to start as cathedral-style
benevolent dictatorships and move toward bazaar-style
contribution or meritocratic-style governance (or both) as
they mature."

It mentions projects like Linux and GNU Emacs and Apache and
Ubuntu, and their various systems.  It then discusses each a
little, while giving links to more detailed web pages too.

Then there is an overview of "barriers to adopting a
governance model" before they too are discussed more.  I
found it interesting that it said "the goal is to make the
[governance] model simple but effective."  And also "it is
never too soon to define a suitable governance model."

But I urge you to read that whole document for yourself.  I
can't possibly excerpt everything which is important or
useful to know.

But it's not just about governance, it's also about
contributors and contributing.  Which we are discussing.

The there is a section on making decisions.

"Decision making in an open development project appears, at
first sight, to be a complex issue and is central to many of
the fears examined in the previous section. Many people
know, for example, how difficult it can be for a committee
to reach a decision.  Documenting the process by which
decisions are made is therefore a key part of a governance
model, and it is worth taking a little time to explore the
various approaches commonly taken to prevent deadlock
situations from occurring in open development communities."

"Decision making in open development projects can range from
fully centralised to fully decentralised.  Through necessity
and familiarity, nearly all projects will start life with a
centralised model, with a small number of initial
contributors, perhaps as few as one.  As a result, all
decisions are made by this small team.  For a small team,
centralising the decision making is easy, and is akin to
what is found in closed projects.  However, as a successful
project grows, more and more people will be willing to
contribute to the objectives of the project.  The decision
making process may need to evolve accordingly."

It then goes into detail about some governance models, but
in that discussion it says:

"When writing the decision making section of a governance
document for a centrally controlled project, it is important
to indicate that while the decision making power is
centralised, the distributed community is expected to inform
that decision through debate."

I certainly hope that whatever governance model is agreed
upon that open discussion should continue to guide gramps.
Furthermore, I would argue that it should always be open and
public, and by that I mean here in the gramps-devel list.
If a council or board of directors or some sort of guidance
group happens, then I would argue that its voting or
decision-making should also be public, here on gramps-devel.

Since immediately after those last words, it goes on to say
"Failure to do this may alienate some individuals, ..."

The "Meritocracies" section starts by saying:

"While some projects maintain tight control over the
decision making process, others feel it is more effective to
allow the community as a whole to make decisions.  In this
case, there is an increased need for a formal decision
making process, since there is no single person able to
break a deadlock."

I too dislike the "single person" model which gramps is
presently using, and would like to see decisions made by a
larger group, somehow, to be determined.

It comments that in such a system "leadership figures
... must ... wield their perceived authority with care."

I think that in gramps that hasn't always happened.

That meritocracy section says many things I feel are good,
for instance:

"As with the benevolent dictator model, decisions are made
by listening to the community and eventually taking action
based on the consensus that emerges."

But again, I urge you to read it all for yourself.

For instance, that section adds that "most decisions within
a meritocracy are made in a way that is very similar to that
of projects operating under a benevolent dictator model.
That is, once someone has earned the merit to allow them to
define a course of action, the use of lazy consensus allows
them to just go ahead and take whatever action they want."

The last major section is "How to draw up a governance
document" and again I certainly think gramps needs such a
document, probably on the wiki, I imagine in a
write-protected manner.  I am not aware that gramps has
anything like that now.

It closes with many reference links, which so far I haven't
gone to.

In summary, the recent activity on this thread has motivated
me to write this note.

While it is somewhat wordy (most of you won't be surprised),
my two main points are that I think project governance
should be discussed first, and then other things, whatever
they are, afterward.  And second that I believe that some
sort of governance which contains more people that just one
is needed by the gramps project.

This note is somewhat of an overview and I hope this thread
continues, with details being proposed and considered.  I
hope that in light of my past service that I will be allowed
to comment, and take part in whatever discussion evolves.
Whether you all want me to participate in that discussion I
leave up to you.

Thank you for reading this.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

enno
In reply to this post by John Ralls-2
Op 01-04-18 om 18:08 schreef John Ralls:

>
>> On Apr 1, 2018, at 8:02 AM, Enno Borgsteede <[hidden email]> wrote:
>>
>> Op 1-4-2018 om 02:26 schreef Tim Lyons:
>>> In contrast, when I just submitted commits straight to the master, I pulled
>>> the latest commit, made sure I was applying my change on top of that commit,
>>> and then pushed the change. I could do this for the same change for several
>>> versions of Gramps one after the other. (There was a tiny chance that
>>> someone had made a commit between when I got the latest and when I pushed,
>>> but the chance was tiny).
>> I'm not  a core developer for Gramps, but I do think that the core developers should be trusted to do standard push, no forced push, and for them, PRs are just an unwanted sort of bureaucracy. This is because, when tests fail, Git offers more than enough means to correct.
> I don't know what this has to do with a requirement for PRs. Yes, if you do a straight merge then history can get a bit messy, and one must be careful that PRs are based on the right branch so that they don't wind up duplicating commits on both sides of the merge. Not a big deal and easy to see in GitHub: If the PR has commits from more than one author it's likely that it's crossing branches.
Well, what I meant to say is that core developers should not be forced
to submit pull requests, but be allowed to push, like I can push at
work. I'm part of a small team where everyone pushes bug fixes to the
main development branch, and where we use feature branches for other
things, also without PRs.

In the rare case that a nightly build or test fails, a correction is
made, and there's enough trust in our team to work without code reviews,
mostly. One can ask for one, which is of course easy when you work on
one location, and in such a case we should use a PR for Gramps. PR
should not be standard though, IMO.

I also tried to address Tim's comment about a push failing when another
person pushed between his last pull --rebase and his push, because I
know that in such a case, I just do another pull --rebase, and that's it.

And I'm writing this, because I understand Tim's comment as saying that
a requirement for PRs pushes experienced developers away from Gramps.

I'm writing this as a sort of bystander, because I don't contribute any
code for 4.2 or 5.x myself, and have my own clone for my personal 3.4.9.
It's just that I understand how the requirement for PRs pushes people
away, and know how well things work when you have core developers that
all have rights to push.

Regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
In reply to this post by Nick Hall
In reply to Paul Franklin's post:

Paul,

You are certainly welcome to participate in this discussion.  Just
because you decided to stop contributing doesn't mean that you can't
start again.

I intended to discuss all three policy items on the roadmap in separate
threads.  This thread, probably the most important, was about project
governance, but it drifted off-topic.  Feel free to discuss the original
subject.

At the end of this process we should write a formal project governance
document, even if we decide to keep the current model.

Regards,


Nick.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Paul Franklin-5
On 4/1/18, Nick Hall <[hidden email]> wrote:
> At the end of this process we should write a formal project governance
> document, ...

I agree.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
In reply to this post by Nick Hall
Devs,

It has now been over a week since my original post, and nobody has
really answered my questions.

Would you like to see a change to our governance model?  If so, what
type of model would you prefer?

Please start to propose details of any changes you would like to see.

Regards,


Nick.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Paul Franklin-5
On 4/2/18, Nick Hall <[hidden email]> wrote:
> Would you like to see a change to our governance model?

Well, I don't claim to be speaking for anybody but myself, so
I certainly hope and expect that others will speak up too, but
as for me, I already said:

> I too dislike the "single person" model which gramps is
> presently using, and would like to see decisions made by a
> larger group, somehow, to be determined.

I certainly thought those words said I'd "like to see a change."

> If so, what type of model would you prefer?
>
> Please start to propose details of any changes you would like to see.

Well, those are two types of questions as far as I can tell.

I think those words of mine already answered the first
question, at least generally.  Is that a sufficient answer
for you to know what "type of model" I'd prefer?  Or do
you want more details?  If so, can you be more specific
about the sorts of details you want, remembering that I
am only asking about your first question, "what type of
model" I'd like. Multi-person vs. a single person.

If my words answer your first question, what type of
governance model I'd like to see happen, you then say
please "propose details of any changes" I want.

Well, I already said one of those details, when i said:

> I certainly hope that whatever governance model is agreed
> upon that open discussion should continue to guide gramps.

But I added:

> Furthermore, I would argue that it should always be open and
> public, and by that I mean here in the gramps-devel list.

And then I added:

> If a council or board of directors or some sort of guidance
> group happens, then I would argue that its voting or
> decision-making should also be public, here on gramps-devel.

If the claim is continued to be made that there already is a
"guidance group" for gramps, and if the consensus or vote
or whatever says it should continue, then I say that IMHO "its
voting or decision-making should also be public, here on
gramps-devel."  Which is certainly not happening now, IMHO.

But to back up a little, when you say "please start to propose
details of any changes you would like to see," I think that is a
stage which shouldn't come instantly.  I think the stage which
should happen instantly is the first and second questions you
asked.

> Would you like to see a change to our governance model?

> If so, what type of model would you prefer?

Obviously, if the consensus to "would you like to see a change"
is no, then we can skip the second question ("what type").  But
if some people want change, and others don't, then I think we
need to solve that first, before any "details" of any "governance
model" can be discussed.  At least it certainly seems to me
that the details of a single-person leadership might well be
different than the details of a multi-person leadership.

But what does everybody think, about some of the things I've
said, about the questions Nick and I have raised?  What are
your answers to some of these questions?  I don't like a
single-person leadership, whether it Nick or me or anybody
else.  If you like it, I'm open to be convinced: convince me.
If you don't like it too, say so.  Etc.

Thanks.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
In reply to this post by Nick Hall
 > If the claim is continued to be made that there already is a
 > "guidance group" for gramps, and if the consensus or vote
 > or whatever says it should continue, then I say that IMHO "its
 > voting or decision-making should also be public, here on
 > gramps-devel."  Which is certainly not happening now, IMHO.

At present there is no guidance group.  We have a benevolent
dictatorship and as such there is no need for a decision making
process.  All decisions I make are either posted to the list or the
relevant pull request.

 > But what does everybody think, about some of the things I've
 > said, about the questions Nick and I have raised?  What are
 > your answers to some of these questions?  I don't like a
 > single-person leadership, whether it Nick or me or anybody
 > else.  If you like it, I'm open to be convinced: convince me.
 > If you don't like it too, say so.  Etc.

So far, to summarise, Paul Culley thinks that we should have a leader
but is uncomfortable with a single person having absolute veto power and
Paul Franklin advocates a multi-person leadership. There have been no
other comments so I can only assume that everyone else is happy with the
current situation.  Let us know if this is not the case.

Regards,


Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

enno

Hello all,

 

This is a reply to Nick and the list, written with Mail for Windows 10, to test if that makes any difference for mails getting through.

 

On the subject of leadership, I think that a benevolent dictatorship is not ok, exactly because of the comments cited from both Pauls. IMO, a 3 person leadership should be preferred, for which my candidates would be, in alphabetical order:

 

  • Nick Hall
  • Tim Lyons
  • John Ralls

 

This list is based on my personal perception of seniority and leadership in software engineering and management, as far as I have observed these aspects in the Gramps project.

 

Regards,

 

Enno

 

 

Verzonden vanuit Mail voor Windows 10

 

Van: [hidden email]
Verzonden: dinsdag 3 april 2018 18:38
Aan: [hidden email]
Onderwerp: Re: [Gramps-devel] IMPORTANT: Gramps project governance

 

> If the claim is continued to be made that there already is a

> "guidance group" for gramps, and if the consensus or vote

> or whatever says it should continue, then I say that IMHO "its

> voting or decision-making should also be public, here on

> gramps-devel."  Which is certainly not happening now, IMHO.

 

At present there is no guidance group.  We have a benevolent

dictatorship and as such there is no need for a decision making

process.  All decisions I make are either posted to the list or the

relevant pull request.

 

> But what does everybody think, about some of the things I've

> said, about the questions Nick and I have raised?  What are

> your answers to some of these questions?  I don't like a

> single-person leadership, whether it Nick or me or anybody

> else.  If you like it, I'm open to be convinced: convince me.

> If you don't like it too, say so.  Etc.

 

So far, to summarise, Paul Culley thinks that we should have a leader

but is uncomfortable with a single person having absolute veto power and

Paul Franklin advocates a multi-person leadership. There have been no

other comments so I can only assume that everyone else is happy with the

current situation.  Let us know if this is not the case.

 

Regards,

 

 

Nick.

 

 

 

------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________

Gramps-devel mailing list

[hidden email]

https://lists.sourceforge.net/lists/listinfo/gramps-devel

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Paul Franklin-5
In reply to this post by Nick Hall
On 4/3/18, Nick Hall <[hidden email]> wrote:
> At present there is no guidance group.  ...

Yes, that's what I believe too, and have for quite a while.

But the claim used to be made that Nick and Benny and Brian
were the "guidance group," so I'm glad that claim is no longer
being made.

But let's not get distracted over such things.

We are discussing the "high-order bits":

> Would you like to see a change to our governance model?

> If so, what type of model would you prefer?

"Keep those cards and letters coming in."

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Helge.Herz-2
In reply to this post by enno
Hello all,
even if I'm more or less inactive in the last time here I still have the
state as developer at the bug tracker. So I think it's necessary to
reply to prevent a silent participation like "no comment means every
thing is accepted":
I give my 1+ for Enno's reply.

Helge

Am 03.04.2018 um 19:33 schrieb Enno Borgsteede:

> Hello all,
>
> This is a reply to Nick and the list, written with Mail for Windows 10,
> to test if that makes any difference for mails getting through.
>
> On the subject of leadership, I think that a benevolent dictatorship is
> not ok, exactly because of the comments cited from both Pauls. IMO, a 3
> person leadership should be preferred, for which my candidates would be,
> in alphabetical order:
>   * Nick Hall
>   * Tim Lyons
>   * John Ralls
>
> This list is based on my personal perception of seniority and leadership
> in software engineering and management, as far as I have observed these
> aspects in the Gramps project.
>
> Regards,
> Enno
>
>  
>
>  
>
> Verzonden vanuit Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
> voor Windows 10
>
>  
>
> *Van: *Nick Hall <mailto:[hidden email]>
> *Verzonden: *dinsdag 3 april 2018 18:38
> *Aan: *Gramps Development List <mailto:[hidden email]>
> *Onderwerp: *Re: [Gramps-devel] IMPORTANT: Gramps project governance
>
>  
>
>> If the claim is continued to be made that there already is a
>
>> "guidance group" for gramps, and if the consensus or vote
>
>> or whatever says it should continue, then I say that IMHO "its
>
>> voting or decision-making should also be public, here on
>
>> gramps-devel."  Which is certainly not happening now, IMHO.
>
>  
>
> At present there is no guidance group.  We have a benevolent
>
> dictatorship and as such there is no need for a decision making
>
> process.  All decisions I make are either posted to the list or the
>
> relevant pull request.
>
>  
>
>> But what does everybody think, about some of the things I've
>
>> said, about the questions Nick and I have raised?  What are
>
>> your answers to some of these questions?  I don't like a
>
>> single-person leadership, whether it Nick or me or anybody
>
>> else.  If you like it, I'm open to be convinced: convince me.
>
>> If you don't like it too, say so.  Etc.
>
>  
>
> So far, to summarise, Paul Culley thinks that we should have a leader
>
> but is uncomfortable with a single person having absolute veto power and
>
> Paul Franklin advocates a multi-person leadership. There have been no
>
> other comments so I can only assume that everyone else is happy with the
>
> current situation.  Let us know if this is not the case.
>
>  
>
> Regards,
>
>  
>
>  
>
> Nick.
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
>
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> _______________________________________________
>
> Gramps-devel mailing list
>
> [hidden email]
>
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>  
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
On 03/04/18 22:21, Helge Herz wrote:
> even if I'm more or less inactive in the last time here I still have the
> state as developer at the bug tracker. So I think it's necessary to
> reply to prevent a silent participation like "no comment means every
> thing is accepted":
> I give my 1+ for Enno's reply.

Thanks.  Even currently inactive developers should reply so we know
their opinion.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Wallingford-3
In reply to this post by Paul Franklin-5
On 04/04/18 09:00, Paul Franklin wrote:
> On 4/3/18, Nick Hall <[hidden email]> wrote:
>> At present there is no guidance group.  ...
>
> Yes, that's what I believe too, and have for quite a while.
>
> But the claim used to be made that Nick and Benny and Brian
> were the "guidance group," so I'm glad that claim is no longer
> being made.

I was closely involved with the Gramps project for about 11 or 12 years.

Though I have never been a 'developer', I was responsible for all of the
web services - website generally (WordPress), bug tracker (Mantis) and
documentation (MediaWiki).  I was, in effect, shoulder-tapped at the
time.  And when I no longer felt like doing the job, it was transitioned
to Sam M.

I was around for the changing of the guard, as Don A. relinquished
overall control to Brian M.  I watched the handover from Benny M. to
Nick H. for the overall coding responsibilities.  And I have not seen
any real problems arise as a result of that management approach.

I personally do not have an issue with the benevolent dictator approach.
  As people arise with the willingness to work co-operatively and
collectively, they are generally provided with responsibilities of some
sort.

Brian, in that time, has felt (I'm putting words in his mouth!)
satisfied with the direction and approach of things generally.  On
issues of my role, he would trust my judgment to raise significant
problems early - and then he would take more advice, but ultimately
carry the can for the decisions...

Gramps, IMHO, does not have the size or pool of developers to want or
need a management guidance group, and I would fear that the overheads
may well drive off other potential developers.

If ever there is a dispute, I feel confident that I can trust Brian M.
to ultimately make decisions for the long term good of the project - be
that issue web stuff or coding direction.

Nick Wallingford
Tauranga, NZ

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
123