IMPORTANT: Gramps project governance

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

Re: IMPORTANT: Gramps project governance

Paul Franklin-5
On 4/3/18, Nick Wallingford <[hidden email]> wrote:
> I was closely involved with the Gramps project for about 11 or 12 years.

Please let me join the many gramps people who have
thanked you for your immense amount of work over the
years.  We all valued it and were and are grateful -- even
if that did not get said as often as it should have been.

> I personally do not have an issue with the benevolent dictator approach.

OK.  That's what we're doing, soliciting opinions.

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

Well, none of us want that, but I'd guess just the opposite.
I'd guess that "project governance guidance" wouldn't be
needed all that often, the same as such usually-major
decisions don't happen all that often now (IMHO).  But I
can imagine the possibility I am wrong.  Time will tell.

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

Ah, but Brian M. is no longer the "benevolent dictator."

I don't think anybody is saying that former gramps people
shouldn't be allowed to express their opinion, should they
ever desire to, no matter how long it's been since they
last "developed" (or expressed their opinion, etc.).  In fact
I believe Nick (Hall) just said that, albeit in fewer words.
They can post to gramps-devel, just like we all can.

But given your long history, and service to gramps, let me
throw out an idea which first crossed my mind when I read
Enno's post.  Mind you, I am not formally proposing this
(although I think it might well be a good idea), but instead
I am mentioning it since we are discussing "what model
of governance" should gramps have.

I like Enno's idea of "three" people, since among other
things I think that would preclude the possibility of any
one person having a "veto power," one of PaulC's worries.

But I'd like to mention the idea that maybe rather than
having a group of three people, we have a larger group,
with "three" as the minimum quorum for a decision.

And I would imagine any odd number would provide the same
capability so something would have to be done if it turned
out to be the case that only four (say) of the council, group,
etc., happened to have the time to be reading gramps mail
at the moment.  Maybe the last person (in the council group)
to express an opinion would have to drop out (unless another
joined the discussion, making it "odd" again).  Maybe the
person (of the then-current discussion participants) who
joined gramps most recently would drop out, not have their
vote counted in whatever the particular discussion was?
Just to make sure the number of deciders was always not
even.  That might be one way to avoid tie votes.  I don't have
a firm idea of how to make sure ties don't happen.  But if
only a small, fixed-number group existed (say three), what
if one of them is on holiday and not reading gramps things?

But if the consensus is to have a multi-person guidance
group, perhaps the net of who might be in such a group
should be cast a little wider?  Maybe people who don't code
heavily but who do a lot of work for gramps should be in it?

Sam comes to mind for instance (thinking of you, NickW),
since I have a hunch that most of us don't even know all
the work he does on the wiki, and even more now that he
is the official webmaster.  PaulC comes to mind too, since
IMHO I doubt that anybody had coded or changed as many
gramps lines in the last six months as he has.  Maybe for
the last year also, at a guess.  I think his devotion to
gramps is clear, and I think he may have management
experience in a previous life.  But I can only hope he'd be
willing (to be part of such a group, should it be decided on);
I don't have any knowledge.

But if the consensus is to have a three-person group,
then I certainly have no problems with the three that Enno
proposed.  (Even if I think the group should be larger, and
maybe even including long-time gramps non-coders like
Enno himself).

Food for thought.

"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

Nick Wallingford-3
On 04/04/18 16:14, Paul Franklin wrote:

>> 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.
>
> Ah, but Brian M. is no longer the "benevolent dictator."

nickw@black:~$ whois gramps-project.org
Domain Name: GRAMPS-PROJECT.ORG
Updated Date: 2018-01-27T02:03:01Z
Creation Date: 2005-02-28T00:56:54Z
Registrant Name: Brian Matherly

Brian has never been overtly hands on, but as I understand it, he still
feels responsibility for the project.

When I managed web stuff, he did not interfere but ensured I considered
relevant aspects of communications and consultation.  But he effectively
delegated responsibilities to me.  I would expect that the
development/coding components of the project are managed in a similar
manner, with one, or (at times) several of the developers being
responsible for the specific application development stuff.

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
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Nick Hall
On 04/04/18 08:22, Nick Wallingford wrote:
> Brian has never been overtly hands on, but as I understand it, he
> still feels responsibility for the project.

Yes.  Not only is the domain registered in Brian's name, but he is also
in control of the project finances.  As far as I am concerned he still
retains ultimate authority.

>
> When I managed web stuff, he did not interfere but ensured I
> considered relevant aspects of communications and consultation. But he
> effectively delegated responsibilities to me.  I would expect that the
> development/coding components of the project are managed in a similar
> manner, with one, or (at times) several of the developers being
> responsible for the specific application development stuff.


The development/coding and web management components are still
delegated.  This effectively creates a group of three:

* Brian Matherly
* Nick Hall
* Sam Manzi

I also feel confident in Brian to make decisions for the long-term good
of the project.

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

GRAMPS - Dev mailing list
In reply to this post by Nick Hall
Hello Gramps Friends,

I've been following this thread with interest. While I haven't been
active in Gramps code development for a number of years, I am still
heavily invested in Gramps (both personally and for the integrity of my
research). That is why I have continued to keep paying the bills and
acting as backup web admin to make sure we "keep the lights on". I also
lurk on the mailing list to keep tabs on things. Occasionally I offer
advice to Nick or others who still know me.

Here are my primary goals for Gramps (in priority order)
1) Design integrity
2) Application stability
3) Application usability
4) Web presence (Wiki, webpage, documentation, etc)
5) Translations
6) Releasing new features
7) Increasing community participation

While I value all of these goals, you can infer from my list that I
would choose "design integrity" over "increasing community
participation" if there were trade-offs to be made. For example, it
would be OK with me for there to be a few more steps to get code
committed (e.g. PRs) if that results in a better design.

In order to support the goals as I prioritize them, I think it is key
that we appoint technical leaders who are willing and able to advocate
for consistency in design and architecture. Ideally, these leaders have
a long standing history with Gramps and a broad exposure to the code
base so that they can propagate architectural patterns and consistency.
That is why I appointed Nick to take the lead years ago and why I
continue to have high confidence in him today. But I can see merit in
having a committee approach as long as the committee members can
collectively carry the goals forward.

When I originally appointed Nick, I wanted to make sure that I took a
large step back so that Nick didn't end up standing in my shadow and so
he could lead confidently. My motivation at the time was that I did not
want to continue to make the large time commitment that was required by
the role. If the consensus moves us more toward a committee approach and
the community would like to have me participate in that capacity, then I
would be willing to increase my participation level (although not all
the way to the level that it was when I was the single leader).

So this is my official offer to volunteer for a Gramps Governance
Committee (if such a thing comes to exist). But there have been names
mentioned of other capable people as well. I would be happy to let other
people serve instead of me.

Cheers,

~Brian



------------------------------------------------------------------------------
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 wish the discussion would stick closer to what type of
governance gramps should have, not get bogged down
in details about particular people, or particular goals.

We are trying to decide (at least I hope so) whether gramps
will have a single-person or a multi-person governance.

Then the rules for whatever it is can be decided upon. And
indeed the person or the people also.  And the goals and
whatever else too.  Personally, I'd advocate for governing
council members to be voted upon, as opposed to appointed
for life say, but that's for everybody to decide.

I am willing for anybody to be in the governance council,
should it be decided that something like that should be
created, but I would like one qualification to be people
who are currently active in the gramps effort, who are
participating in the gramps community at the moment.
And to require "activity" as a condition of membership.

I want people who are actively following along with what
gramps is doing and how it is doing it.  Not just what it is
going to do a year from now, once a year.  And especially
not as a reward for what they did for gramps years ago.
I don't want a "rubber-stamp congress" like China has,
routinely accepting what one leader has already decided.

Given a choice, I'd like governing people to be actively
"doing" something also.  I can recall major decisions in
the past where once the decision was made, and we were
inevitably on that path, the people decided to be inactive.

But I am perfectly happy with people who don't participate
in the list every week.  Or even every month.  I certainly think
of Josip or Tim as an active member of our community even
when sometimes a long time passes between comments
or activity.  (That's one reason I am not particularly happy with
the clarion call for people to express their opinions instantly,
since I don't think there is any particular reason to hurry in
this decision-making process.  We don't have any deadline.)

But that's why I suggested that a "quorum" concept might be
useful, to allow for governance members not being active at
the moment.  With perhaps some sort of "sunset clause" in
case the inactivity becomes more consistent (a year?).  (And
as far as that goes, I'd like to see "term limits" if a one-person
model is decided upon. Three years?  More?  Less?)

Don is still one of the names that SourceForge says is in
charge of the gramps project stuff there, but I can only
recall him posting on the gramps-devel list twice, years
ago, in the eight years I've been reading it. So I wouldn't
put him into the "active" category.

And as far as who the domain name is registered to, I
certainly know that Brian is the gramps Treasurer and has
been for years.  He is the one that all PayPal donations
go to and I am happy to have him continue that as long
as he is willing.  I hope he'll be willing to do that whatever
type of gramps governance is decided upon.

I'm also happy that he said that he is willing to serve on
a gramps council or board of directors or governance
group, whatever it is decided to be called, if that is what
is decided upon.  And become correspondingly active.

But as I've said, I think it could be useful to have more
people in that group than just a few.  And I especially
think there should be no "chairman of the board" or any
stated leader of the group.  If we end up with that sort
of thing, that will be too close to the "benevolent dictator"
model that we presently have for my taste.

Once people (in the governance group) acknowledge one
person as the person whose opinion is most important,
perhaps more important than others, then it will be drifting
too far from an egalitarian democratic meritocratic group
for my tastes.  I am reminded of the old line from George
Orwell's "Animal Farm" that "all pigs are equal but some
pigs are more equal than others."  I don't want that.

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

GRAMPS - Dev mailing list
Hi Paul,

On 4/4/2018 12:17 PM, Paul Franklin wrote:

> I wish the discussion would stick closer to what type of
> governance gramps should have, not get bogged down
> in details about particular people, or particular goals.
>
> We are trying to decide (at least I hope so) whether gramps
> will have a single-person or a multi-person governance.
>
> Then the rules for whatever it is can be decided upon. And
> indeed the person or the people also.  And the goals and
> whatever else too.  Personally, I'd advocate for governing
> council members to be voted upon, as opposed to appointed
> for life say, but that's for everybody to decide.

I think we came at this from different approaches. I think it would be
wise to first decide *what* you want to accomplish (goals) and then set
up a governance structure to support those goals.

Also, before the governance structure is decided on, it would be
appropriate to ask questions like these:
* What are the responsibilities of the committee?
* What kinds of decisions do you expect the committee to make?
* How quickly should the decisions be made?

I think we all have our own ideas of the purpose of a governance
committee. I was trying to expose my ideas so that others could compare
with their own.

It is clear to me that you advocate for a multi-person governance
committee instead of a single person approach. But your motivation is
unclear to me. Can you state (in one or two sentences) what problem we
have now that will be solved better by a committee?

~Brian

------------------------------------------------------------------------------
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 GRAMPS - Dev mailing list
Hello too,
I have to relativize my own vote based on Brian's comments.
I fully agree with this priority order. And if I think about my vote
before I'm pretty sure it was done because I hoped to get such an order
rather by a committee approach than by the current. My personal feeling
(may be I'm wrong) was that currently the priority behind 2) was more
focused on releasing new features than on usability.

Last but not least: The head count of such an committee may be 3 or more
(but odd).
Helge

Am 04.04.2018 um 16:29 schrieb Brian Matherly via Gramps-devel:
...
> Here are my primary goals for Gramps (in priority order)
> 1) Design integrity
> 2) Application stability
> 3) Application usability
> 4) Web presence (Wiki, webpage, documentation, etc)
> 5) Translations
> 6) Releasing new features
> 7) Increasing community participation
...


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

Paul Franklin-5
On 4/4/18, Brian Matherly via Gramps-devel
<[hidden email]> wrote:
> It is clear to me that you advocate for a multi-person governance
> committee instead of a single person approach. But your motivation is
> unclear to me. Can you state (in one or two sentences) what problem we
> have now that will be solved better by a committee?

I dislike the personalization of this discussion.  I don't
want it to descend into "me vs. you" -- where you (any "you")
argue against a person (any person), instead of arguing
against whatever the person is advocating.

As you have "been following this thread with interest" I
wonder if you (and everybody else) have read:

http://oss-watch.ac.uk/resources/governancemodels

(which both Nick and I have mentioned) and some of the
pointers/links on that page?

Since you have been following this, I imagine that you read
earlier where another developer 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 ..."

When I read that I said "exactly" -- and decided to see if
I would be allowed to participate in the discussion, so that
I too could advocate for such a future.

The "problem" (your word) we have now is that one person
(any one person) can slip more into a "dictatorship" instead
of into "benevolent".  Any group leadership by definition
will have more points of view, more personal histories, more
interests, and so on, than any one person.  It will be less
easy for one person's opinions to prevail, always, if there
are other people who are allowed to vote against them.

I think gramps will greatly benefit from that approach, as
long as discussions about things which matter are made
so that the whole community can participate, and also so
that the votes of the council (and any corresponding talk)
are public, so that the entire community can see who voted
for what, and why.

Communication is vital -- as others have noted.

I hope for a system where any gramps developer can raise
any issue they feel strongly about, have it be discussed (on
gramps-devel), and then if a consensus isn't reached have a
(public) vote taken by the governing council, who have been
following the discussion and perhaps even participating.

I was going to give a detailed recent example where "the
rules set up for everyone" (the phrase used earlier) weren't
followed (IMHO), citing the Nabble thread which started it,
the feature request which was then committed to gramps50,
even though the policy for many years has been that feature
requests are only put into master. I was going to mention
the report the commit broke, the new glade file which breaks
my Gtk (as it has no "id=" on some of the lines, the only
such glade file in gramps), where no verification of entries
(or tooltips) takes place in the new dialog (ignored even
though another bug report on another problem it had also
mentioned it), but instead I have decided that this summary
will be enough to give an idea of what I would like: to
appeal that this p.r. be reverted from gramps50 and put into
master instead, in its current half-baked, half-done state.
And (IMHO) it doesn't even do what the user explicitly wanted.

Who could that decision be appealed to now?  Nobody, as there
is nobody higher than the benevolent dictator.  If he makes up
his mind to do something, or not do something, no appeal
is possible.

I think I'm not the only one who would like that changed.

Gramps will be better if we do.

"Keep those cards and letters coming" (all of you).  8-)

------------------------------------------------------------------------------
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
 > I have decided that this summary
 > will be enough to give an idea of what I would like: to
 > appeal that this p.r. be reverted from gramps50 and put into
 > master instead, in its current half-baked, half-done state.
 > And (IMHO) it doesn't even do what the user explicitly wanted.

 > Who could that decision be appealed to now?  Nobody, as there
 > is nobody higher than the benevolent dictator.  If he makes up
 > his mind to do something, or not do something, no appeal
 > is possible.

Paul,

Your first step should have been to comment on the pull request, stating
what you objected to and proposing changes that would make it
acceptable.  Then there could be a discussion and attempt to reach a
consensus in the PR.

If consensus could not be reached, then I would make a decision. An
appeal could be made to Brian if anyone felt it necessary.

As an alternative, you could also start a thread on this list. Again, we
would attempt to reach a decision by consensus.

If a feature is in a "half-baked, half-done state" then it should be
reverted rather than being put into master.  Features should be
developed in a branch and preferably made public by submitting a PR. 
They should only be merged if they are complete and there are no objections.

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

GRAMPS - Dev mailing list
In reply to this post by Paul Franklin-5
Hi Paul,

On 4/5/2018 1:31 AM, Paul Franklin wrote:
<SNIP>
> Who could that decision be appealed to now?  Nobody, as there
> is nobody higher than the benevolent dictator.  If he makes up
> his mind to do something, or not do something, no appeal
> is possible.
>
> I think I'm not the only one who would like that changed.
<SNIP>

Thanks Paul. I think I understand your position better now.

Cheers,

~Brian

------------------------------------------------------------------------------
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/5/18, Nick Hall <[hidden email]> wrote:

> Paul,
>
> Your first step should have been to comment on the pull request, stating
> what you objected to and proposing changes that would make it
> acceptable.  Then there could be a discussion and attempt to reach a
> consensus in the PR.
>
> If consensus could not be reached, then I would make a decision. An
> appeal could be made to Brian if anyone felt it necessary.
>
> As an alternative, you could also start a thread on this list. Again, we
> would attempt to reach a decision by consensus.
>
> If a feature is in a "half-baked, half-done state" then it should be
> reverted rather than being put into master.  Features should be
> developed in a branch and preferably made public by submitting a PR.
> They should only be merged if they are complete and there are no objections.

That's right, argue against me, as a person, rather than
what I am advocating: changing "benevolent dictatorship"
into some sort of multi-person leadership, with any and
all discussions and voting public, on gramps-devel (and
not on GitHub, which is not indexed by Google, and not
archived by Nabble, etc. -- as I have said for years now).

------------------------------------------------------------------------------
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
Thank you for your opinion Don.  You are certainly entitled
to it and I respect that.  The same as I hope you respect my
right to have my opinion.

The rules for deciding whatever is to be decided haven't been
discussed yet, but I would hope it would be based on "one
person, one vote."  If so my vote will cancel yours, I'm afraid.

You mention Python and the linux kernel and it is certainly
true they follow a BDFL governance model.

But the web page I recently mentioned (again) also says that:

"GNU Emacs is ... governed by Richard Stallman. It is worth
noting, however, that Stallman no longer has the same role
that he had when Raymond wrote his essay, and the current
lead maintainers run the project with a more open ... model."

While the linux kernel is important, I think everybody would
agree that it would have gotten nowhere without the GNU
software and the FSF.  Note that it says "lead maintainers."

That web page also says:

"Apache HTTPD, as an Apache project, follows a formal
meritocratic structure. It invites anyone to contribute
their code."

I think it could be argued that Apache is at least as much
of a success as Python is.

It also says:

"Ubuntu has a benevolent dictator, in the form of the
project’s founder and funder Mark Shuttleworth. However,
many decisions are delegated to the Community Council and
Technical Board, whose members are appointed by the
community through a meritocratic process."

In my opinion, Ubuntu has more users than gramps will
ever have, in its wildest dreams.

The fact that some projects are BDFL and some follow a
meritocratic model seems to me to be neatly summarized
when they say:

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

I still think it is time for gramps "to move along this spectrum."

What do you all think?

------------------------------------------------------------------------------
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
On 06/04/18 17:42, Paul Franklin wrote:

> The rules for deciding whatever is to be decided haven't been
> discussed yet, but I would hope it would be based on "one
> person, one vote."  If so my vote will cancel yours, I'm afraid.

Please don't cancel out Don's vote - let your vote cancel out my vote
instead.  I respect Don's role in Gramps too much to let your vote be
equal to his...

> I still think it is time for gramps "to move along this spectrum."

I disagree, as I believe the project's management over the long term,
and over recent times, has been effective and useful.  I do not believe
in introducing change without a demonstrated need, or a widespread
desire to change.

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
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT: Gramps project governance

Serge Noiraud-2
In reply to this post by Nick Hall
Hi,

Le 25/03/2018 à 17:31, Nick Hall a écrit :

> 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.
As Don wrote on another separate email :


 > Sorry for this being a separate email. I normally follow this list using the digest format, which does not suit itself to replies. While I have not been active in many years, I am still around.

 > My opinion is that the "benevolent dictator" model is the best for a project like gramps. A project needs a clear vision and that is the responsibility of the BD.

I agree with that ( +1 )

 > As examples, both the Linux kernel and Python follow the BDFL ("benevolent dictator for life") model. Both of these projects are highly successful and have a clear direction. Many people contribute to the projects, but in the end, the BD keeps the project focused.

 > A rule by committee model tends to pull the project in many different directions, and the project loses consistency. While each individual decision may seem to be a good point decision, no one is there to keep consistency and provide a long term direction. This model also allows the project to be hijacked and taken into tangential directions by a few. In the early days of the project, we had many who insisted that we had to switch to the QT or TK toolkits, or adopt the Gedcom XML as the internal format, or abandon the desktop model and focus solely on web based projects.

I agree

 > The benevolent dictator model means that if you want a significant change, you need to be able to convince the person at the top that your idea is worthwhile. Chances are, if you can't convince the BD, the general users won't be happy either.

Is this a problem ? I got it when I added the geography to the project (thanks brian)

 > When I abdicated the role of BD, I could have set up a committee to replace me. However, I chose instead to have Brian Matherly replace me. He had a good idea of the direction of the project, he had excellent leadership skills, and he had good people who could advise him. The model has continued to work well, considering the project is in good shape, and has been highly active for almost 17 years.

 > - Don Allingham, retired benevolent dictator

Serge

------------------------------------------------------------------------------
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 Wallingford-3
On 4/6/18, Nick Wallingford <[hidden email]> wrote:
> I respect Don's role in Gramps ...

On 4/3/18, Nick Wallingford <[hidden email]> wrote:
> 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 ...

Yes, I respect Don's role too. Without him none of us would
be involved with gramps since after all it wouldn't exist.

If Don or Brian or Benny were still the one and only "benevolent
dictator" for gramps we probably would not be discussing gramps
governance at all.

But we'll never know.

That isn't the case and isn't likely to be the case ever again.

Remember, we are not discussing leadership and governance
and things like communication and judgement in the abstract,
we are discussing it in the particular.

We are discussing our present "benevolent dictator" and if we
want him to continue being the sole person controlling gramps.

Neither Don nor Brian nor Benny are commenting on the list
every month, guiding gramps, making decisions, etc.

Personally, I don't find having warm memories of some previous
person a sufficient reason to want to continue with another in
charge.  I believe the phrase is "comparing apples and oranges."

I am not persuaded by statements saying Don was a wonderful
benevolent dictator and so we should continue with our present
benevolent dictator.  Or that Brian was a wonderful benevolent
dictator and so we should continue with our present one.  Or
that Benny was a wonderful one, or that Linus Torvalds is a
wonderful one.  While all of those people may be wonderful
leaders none of them are our present leader.

I still believe that a council-based governance model is the best
one to cope with the frailties and foibles and imperfections of any
leadership person, such as the present one.

The fact that people think that Franklin Roosevelt or John Kennedy
or Barack Obama (or whichever one you admire) was a great one
does not mean that the present president is a great one, just for
being the current president.

------------------------------------------------------------------------------
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 Nick Wallingford-3
Op 06-04-18 om 09:05 schreef Nick Wallingford:
> On 06/04/18 17:42, Paul Franklin wrote:
>
>> The rules for deciding whatever is to be decided haven't been
>> discussed yet, but I would hope it would be based on "one
>> person, one vote."  If so my vote will cancel yours, I'm afraid.
>
> Please don't cancel out Don's vote - let your vote cancel out my vote
> instead.  I respect Don's role in Gramps too much to let your vote be
> equal to his...
So you like dictatorship ... meaning that some votes are more equal than
others :-)

>
>> I still think it is time for gramps "to move along this spectrum."
>
> I disagree, as I believe the project's management over the long term,
> and over recent times, has been effective and useful.  I do not
> believe in introducing change without a demonstrated need, or a
> widespread desire to change.
I see a demonstrated need when a conflict arises between a developer and
the BD, and it seems to be personal, as seems to have been the case
between Paul Culley and Nick Hall. From what I've read it was about Nick
'not liking' Paul's changes, and Paul 'not liking' Nick's reaction.

I'm a professional software engineer, and there are many thing that I
don't like. Many of these are user interface things, and others are
complex code, and unit tests. And when I have a problem with either I am
prepared to discuss and defend my case, and agree to whatever the team
decides. There may be a grumble now and then, and that's part of the
process.

If such a case arises in Gramps, I like to see some sort of group
decision on the subject, meaning that some group decides who is right.
And if it was a user interface change, which I think it was, I'm
inclined to say that it should never be made by a single developer,
because UX is a highly personal thing. And if the group decided that
it's not wanted, I sincerely hope that the developer does not take it
personal. And that will probably be easier if it's a group decision
indeed, and not the BD's.

We've had some things in the past, like a change to introduce EE based
citations (sort of), which was vocally rejected by me. There's also a
DBAPI, that many don't like, and I still use Gramps 3.4, because the new
place hierarchy doesn't really work for me, although I do like the idea.

I appreciate most of our current BD's work, including the hints he gave
me for my own ancestry, which makes Mr. Orwell a 15th degree great grand
uncle, whatever that means, but I think that in some cases a group rule
is better when things get emotional/personal.

Cheers,

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 Wallingford-3
On 08/04/18 00:40, Enno Borgsteede wrote:
>> Please don't cancel out Don's vote - let your vote cancel out my vote
>> instead.  I respect Don's role in Gramps too much to let your vote be
>> equal to his...
> So you like dictatorship ... meaning that some votes are more equal than
> others :-)

I guess for me a better way of saying it is that some opinions resonate
with me more than others.  Remember, when it comes down to it, *I* am
not a developer, so probably would not be allocated a vote in this
process (nor, sadly, would Don).

In my 12 years working in the Gramps project, there has never been any
formal 'voting' on features or approaches.  Not to say there haven't
been multiple issues that generated disagreements - just that they have
been worked through by effective communication of viewpoints.

I don't really have a problem with the creation of a management
committee of sorts.  In my experience, this has been the case to some
extent anyway - our benevolent dictator of the day (talk about using a
pejorative term to bias the discussions!) has, again in my own
experience, never made a sole decision.  My time mostly has involved
Brian as the ultimate arbiter, with me responsible for web stuff and
Nick H. responsible for application development.

If someone did not agree with my work, for instance, both the
developer's list and Brian were always there to appeal my decisions.

But like I say, I'm not a developer.  I guess I could say that my
concern is that I don't want to see time and energy being used to
develop the infrastructure and voting eligibility, etc, systems - I just
haven't seen any/enough disagreements that have not been sorted out
amicably and adequately by the current systems.

Nick Wallingford
Tauranga, NZ



>
>>
>>> I still think it is time for gramps "to move along this spectrum."
>>
>> I disagree, as I believe the project's management over the long term,
>> and over recent times, has been effective and useful.  I do not
>> believe in introducing change without a demonstrated need, or a
>> widespread desire to change.
> I see a demonstrated need when a conflict arises between a developer and
> the BD, and it seems to be personal, as seems to have been the case
> between Paul Culley and Nick Hall. From what I've read it was about Nick
> 'not liking' Paul's changes, and Paul 'not liking' Nick's reaction.
>
> I'm a professional software engineer, and there are many thing that I
> don't like. Many of these are user interface things, and others are
> complex code, and unit tests. And when I have a problem with either I am
> prepared to discuss and defend my case, and agree to whatever the team
> decides. There may be a grumble now and then, and that's part of the
> process.
>
> If such a case arises in Gramps, I like to see some sort of group
> decision on the subject, meaning that some group decides who is right.
> And if it was a user interface change, which I think it was, I'm
> inclined to say that it should never be made by a single developer,
> because UX is a highly personal thing. And if the group decided that
> it's not wanted, I sincerely hope that the developer does not take it
> personal. And that will probably be easier if it's a group decision
> indeed, and not the BD's.
>
> We've had some things in the past, like a change to introduce EE based
> citations (sort of), which was vocally rejected by me. There's also a
> DBAPI, that many don't like, and I still use Gramps 3.4, because the new
> place hierarchy doesn't really work for me, although I do like the idea.
>
> I appreciate most of our current BD's work, including the hints he gave
> me for my own ancestry, which makes Mr. Orwell a 15th degree great grand
> uncle, whatever that means, but I think that in some cases a group rule
> is better when things get emotional/personal.
>
> Cheers,
>
> 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

------------------------------------------------------------------------------
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/7/18, Nick Wallingford <[hidden email]> wrote:
> I just
> haven't seen any/enough disagreements that have not been sorted out
> amicably and adequately by the current systems.

I have.

Else I wouldn't be arguing that we do it differently.  8-)

------------------------------------------------------------------------------
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 08-04-18 om 04:59 schreef Paul Franklin:
> On 4/7/18, Nick Wallingford <[hidden email]> wrote:
>> I just
>> haven't seen any/enough disagreements that have not been sorted out
>> amicably and adequately by the current systems.
> I have.
>
> Else I wouldn't be arguing that we do it differently.  8-)
Same here.

We have quite a small group of active developers, and I'm not one of
them, for reasons mentioned here earlier, and also, because, as an
autist, I can't handle two programming languages at a time. I need to
work with C# at work, so I have to concentrate on that.

My arguments aside, I see that some developers get frustrated, because
they don't understand why their contributions are rejected, and I think
that if such a thing happens, it helps if we can avoid that things
somehow become personal, which I think happens faster with a benevolent
dictatorship.

When some contribution is rejected, it would help a great deal if that's
not because of someone not liking it, but because some common principle
has been overlooked, like the principle of a consistent user interface,
or the scientific experience that icons are not always well understood.

I use the word principle here, because I'm not that much in favor of
rules, unless they really work. That's why I wrote earlier, that the
idea that every piece of code should be reviewed, and changes can only
be made through a PR, looks quite counterproductive to me.

I work in a place where trust is important, and people will make
mistakes, so sometimes, I will have to push an extra commit, because an
automated test run at night shows that my change was not as good as I
hoped it to be. That's part of life, and in most cases, this would most
probably not be detected in any sort of code review, simply because our
software is a tad too complex for that. That's why I'm not that much
into unit tests either.

When big changes are made, we should work with branches, just like I do
at work, and some sort of review will surely be needed when they are
integrated into master. But apart from that, I really prefer to keep
bureaucracy low, and team spirit high, which excludes a BD, IMO.

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
On 08/04/18 13:34, Enno Borgsteede wrote:
> When some contribution is rejected, it would help a great deal if
> that's not because of someone not liking it, but because some common
> principle has been overlooked, like the principle of a consistent user
> interface, or the scientific experience that icons are not always well
> understood.

If a contribution is rejected, it is almost always because it violates a
design principle, often one documented in either the programming
guidelines or UI style guide.

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

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

Both of the examples you give are documented.

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
123