Advisors should have some membership status on this git.

[gschadow]

Related to #246 and someone else mentioned they could not see conrtibuters to this git.

I think what's wrong is that contributing advisors have no membership on this git.

This is a flaw.

There once were specific stakeholders defined and roles and permissions they have. This was all in the #247 text and implemented on the old Trac site.

This is very urgently needed to be brought back. Tim is a great resource, but he should not be the sole member or owner of this git.

[dr-shorthair]

We need the workflow to be sorted first, else we risk conflicts.

For example:

1. A common basic workflow is to not allow any merge into main until N members of the team approve a Pull Request (where N is often 2 or 3). This can be configured very quickly by first ensuring that all the AB have merge capability, and adjusting one standard setting in Git hub.
2. However, if we are planning to have an automated build process, then that needs a temporary branch (e.g. develop) to ensure that the public site is not trashed by a dumb error in the edits. I think that is what @timbrisc is proposing. Then the merge to main would probably be under the control of a smaller set of people (one or two only).
3. Meanwhile, broader permission to close issues would be helpful to triage the list. There are groups of issues where all except one could be closed. For example #171, #180, #181 are all the same issue, and #216, #217, #218, #219 should probably be considered together as a single issue.

[gschadow]

I disagree on several points.

First, we are the project owners, so we need to be a full member authorized to do pretty much anything with this git. And if you don't want to, I do. I didn't agree to move this away out of my hands so I would have to get in line waiting to be served by the single super administrator.

Secondly, about release management, it is wrong to say that development is made on a branch and release on a trunk. I assume that git doesn't have fewer options than SVN or even CVS had. So there are certainly branches and a trunk (head). That being so, current development always goes on on the trunk, while release management creates stable branches off of the trunk, cleans up whatever bugs on the trunk, and moves from alpha, to beta, to release candidate 1, 2, 3 and then to release maintenance, etc. (of course we don't have that complexity, but the principle is the same.) Those are side branches. Development is always on the trunk. This is how serious projects do it.

Example, FreeBSD, there are hundreds of committers committing. And only a few pull requests from the outside. Another example, some random Apache project, also hundreds of committers.

I do not agree that we should have to request edits by cloning our own git and committing to ours and then make pull requests.

Good example was your updating the constants. You should have just done it, responding to the single issue that it originally was "the constants are outdated" fix them all in one go, commit, and done we are. If a committing advisor does something wrong, we fix it. We don't have even the time to scrutinize 6 pull requests because you have changed 6 constants.

Regarding your number 3, ticket adjudication, I filed this but #246 and we don't need to discuss it here.

[dr-shorthair]

My comment was misleading, partly because the language about branch, fork, cache, HEAD etc may be a little different for Git compared with other VCS systems. Let me try again.

In Git everything is in a branch.

In the ucum-org/ucum Git repository, the stable branch is called main. That is a common convention, but it could have been called something else, e.g. HEAD.

For a project with multiple contributors, all development work prior to a formal release must be on a different branch to main. That is the way the other projects that @gschadow refers to work - there are dozens of branches in both those projects.

1. If we all have write-access to the repository, then we can all create branches in ucum-org/ucum repository. These will all be visible to everyone, so the decision about when to merge, etc, does not have to be in response to a PR, but a PR is a good way for the contributor to alert the release-manager that they think that some changes are complete and ready-to-go. This would definitely be easier to manage, as long as people are a bit disciplined in their use of branches and are respectful of the process to merge into main.

2. If we don't provide write-access to the repository, then anyone making a change has to fork the repo and work in their own repository. I've been working in https://github.com/dr-shorthair/ucum, which I forked from https://github.com/ucum-org/ucum. When you work in a fork, if you want to merge changes back into the original repository, then a PR is the formal way to let the release-manager know that there is some new work to consider. They can normally merge with one click (unless there are conflicts, which it is usually left up to the forker to resolve).

[timbrisc]

@gschadow I have invited your account to become a privileged member of this repository. You will need to respond to this invitation to gain access. I have also emailed you some follow-up information. Please confirm receipt of this message.

@dr-shorthair My sincere thanks for your work with this repository and the PRs. Your work is very much appreciated. I'm afraid the entire team is otherwise engaged with the upcoming LOINC Conference in France. Please allow us some time to respond to the issues you have surfaced.

[dr-shorthair]

@gschadow you say 'Development is always on the trunk. This is how serious projects do it.'

The term 'trunk' is not normally used in Git. There are various development patterns for Git and GitHub - I provided a couple of references on Git workflows . I've now found a trunk-based development pattern. While they do cite some very big projects that use it (Google and Facebook!) it is not commonly used in my experience, though scaled trunk-based development looks like a bit of a cross-over.

I can see how this might work for UCUM. It does demand a level of trust in those who have merge privileges on the trunk.

@timbrisc will the extraction from ucum-source.xml to ucum-essence.xml and the conversion to ucum.html be automated? I guess that is what you have been trying to arrange. Note that 'mole` has different values in https://github.com/ucum-org/ucum/blob/main/ucum-source.xml#L1497 and https://github.com/ucum-org/ucum/blob/main/ucum-essence.xml#L213 , so it doesn't look like it is currently working?

[timbrisc]

Closing this issue as the workflow has been established and a new release of UCUM is the topic of the next committee (advisors) meeting.