> 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.
OK, I wasn't aware of either, because I haven't coded anything since
3.4.9, but the impression that I go on this list is that it somehow got
'personal'. Does that mean that I am misreading things? Or did someone
else see a 'personal' thing that wasn't meant as such?
I also don't develop for Gramps anymore at the moment.
Though I like a committee, in my viewpoint, the developer group is too small for that. Also, you more want senior people there for admin stuff and global guidelines. The issue at hand of conflicts would also not be resolved like that. A committee is often just as much under the hand of a single leader. So I would keep it simple and stick with the BDF for Gramps.
In the end, features and suggestions can be discussed. Many things I proposed in the past were not approved by Don. That's just how it is. You can then code something yourself in your own branch, and try it out if you really believe in it. I have forks of several projects with my own additions. Most of the time, you will discuss though and try to find a 'better' way together to solve an issue or scratch an itch. The governance structure does not come into that. You only need that for real conflicts, when no agreement can be found.
For the actual conflicts that spurred the request for different governance. Suppose there is a committee, how would it discuss to have PR and review for all features? It would depend how the committee is 'stacked'. If people disagree, they would still stop coding. Same discussion on mailing lists would be held, with pro and contra. In the end, 'somebody' needs to decide and hard words can follow. Personally, for odes I have 4 open PR (https://github.com/bmcage/odes/pulls) waiting for my review, 20 days open. Probably the developer would be happy if I could look at it faster. However, he has commit access, and prefers to follow the workflow of having somebody else do the PR if not an urgent bugfix or typo. That means I can disagree with the solution, something else might be needed, ... . Normal software development as contrary to a (good) company, we don't have design documents before we start coding, so it is the code that speaks.
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.
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.
I'm quite new in Gramps development (approx. 5 years), but here some remarks out of Germany.
We've seen a lot of arguments for and against different governance styles. All of them are worth considering, but how can we now finalize this discussion in a democratic way? IMHO we should have a formal and transparent ballot, where all developers can raise her votes pro or contra a benevolent dictator. And that's it!We can discuss everything, but not for months (at least we should not). As Sam said, this can be revisited after a while.
I am very conflicted about whether the governance model should be changed.
I am concerned that our already small band of developers is becoming
smaller, and that there has been some disappointment about how contributions
have been handled.
As I have said before, I don’t like the idea of forcing all changes through
the pull request route. I don’t think this will encourage new contributors.
It seems to be that the main current controversy has been about how
disagreements are handled.
(a) If there is disagreement about a commit being reverted, then I think the
person reverting should create a PR for the discussion.
(b) If there is significant disagreement about a change, then the discussion
should be taken onto the mailing list rather than just on GitHub, so that a
wider ‘feeling of the group’ can be obtained.
(c) I hope that by getting a fuller discussion, people will feel that
decisions are more justified.
I strongly agree with Brian’s priorities:
“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)
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.
I know that there is a view that only by adding new features can developers
be kept on-board, but I would urge this be placed a long way below goals 1,
2 and 3.  I think that much can be done by plugins  rather than new
I know that when there are major conflicts, advice is taken from Benny and
Brian. I know that in the past (Sept 2016), Benny has suggested BDFL+board
In the end, I somewhat agree with (what I think) Benny 09 Apr 2018 is
saying, that even if you have a committee, in the end someone has to make a
decision! It does seem as though we already do have a BD with advisors
(though I wouldn’t say that the board members are quite as fixed and
constant as implied by Brian’s 16 Apr 2018 summary).
 I am still using Gramps 3.4.x (like some other people commenting in this
thread), partly because of not getting to grips with the new places scheme,
and partly because it is stable for me. I was pleased that the Evidence
Explained change did not go ahead in the form proposed by others, and I did
do an alternative implementation that I would have been happy with
because it supported configuration that would allow the current scheme to
continue (but I am quite content that it didn't go ahead). I shared the
scepticism of many about changes to the DBMS, and am pleased that changes
were made to improve the design integrity of the change. On the other hand I
am very pleased that the Citations change went ahead because it is
tremendously helpful in keeping my data consistent.
As Enno says (and I agree!) “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 wish someone would implement plugin architecture for GEDCOM imports
similar to what has been done for GEDCOM exports!