Dear members,
On Fri, May 30, 2025, at 18:01, David Kemp via OASIS wrote:
> Here is one summary from StackOverflow <https: stackoverflow.com questions 3611256 forking-vs-branching-in-github>:
>
> [...]
>
> I think there is a difference between collaborative software development and standards development: in our case maintainers are not autonomous actors, they have a fiduciary duty to reflect the OASIS open consensus process using explicit ballots and lazy consensus. For that reason I don't find the pro-Branching "All collaborators can push to the same branch to collaborate on it" convincing. I view it as a disadvantage because it requires contributors to be repo maintainers, which IMO is a risky elimination of guardrails.
Well, git is a version control system, so there are no guardrails
removed, we can always track and revert or adjust.
Please consider git as a means to empower workflows that optimize
the interfaces for diverse individual working styles to maximize
collaboration.
Many OASIS TCs operate with a mix of forks and direct branches
and those I participated in had never a single problem with
that.
The first weeks of the TC saw a lot of motions and procedural
discussions. Simple questions like: Where is the XML Schema,
or what can we tell people what differntiates the 2/3 root
elements source and provenance did not receive simple answers
in the short time it should have taken, no?
For details, cf. below where I listed other examples that
cause a lot of friction that I never encountered in 20 years
of supporting standards creation in OASIS.
I would love to see more emails and content discussions from the
original creators and far less emails and contributions on the
discussions from Stefan, David, and Duncan who all do not really
know why D&TA did submit the material and do not have their own
history of creation of that material.
E.g. I am **burning** to hear from the creators of the tools and
schema files to learn what is the fundament and what was just kind
of derived or experimented with. (Because, the schema files were
not working or not present, and the tool - I understood - was more
targeting small and medium business as a helper - maybe there
were working papers for and from the 55 workshops mentioned?)
>
> I find it comforting to own my own fork where I can do anything including screwing up (which I have done) without any danger to the TC repo. Many TC members are not super familiar with using git and might appreciate the same freedom to work in their own sandbox with guardrails, making them more likely to contribute directly via GitHub rather than submitting ideas via email that have to be interpreted by maintainers.
Some find comfort in their own fork (David and Duncan),
others do not.
For me (Stefan), forks are a marketing instrument from GitHub,
BitBucket, GitLab et al. Every clone is already a fork for all
the branches we do not push / exchange.
This is git, what we are using, plus proprietary vendor
services from GitHub.
Maybe it is also a question of taxonomy / numbers:
https://github.com/sthagen might indicate that more than
thousand such "GitHub" forks is maintaiable by any person,
when these are not primarily intended to write upstream.
But, when I help maintain, I prefer to keep clones from repositories
so that I do not have two such multi-branch siamese twins side by
side on my local machine.
Diversity and easing collaboration are to me the important points here.
Not loss of control, which I clearly do not foresee and never experienced.
>
> So I *SECOND* the fork-and-PR proposal, and observe that we'll need a ballot since we don't have lazy consensus.
>
> David [...]
> -------------------------------------------
> Original Message:
> Sent: 5/28/2025 4:39:00 PM
> From: Stefan Hagen
> Subject: RE: GItHub Branch/Fork Process for DPS
>
> Hi,
>
> On Wed, May 28, 2025, at 17:51, Duncan Sparrell via OASIS wrote:
> > I don't want to start an argument akin to the vi/emacs religious war, but I will anyway because I prefer the more democratic branch process for this TC.
> >
> > I would propose that everyone (ie including maintainers) use the fork&pull process. Maintainers are "allowed" to make their own branches on the OASIS account repo (and they have done so), but most of the membership is not allowed to. Most members need to fork&pull. I propose maintainers also fork&pull instead of creating branches on the OASIS repo. My reasoning is:
> >
> > 1. IMHO we'll get more participation based on my previous experience with several other TC's and in managing large software teams.
> > 2. Maintainers won't get stuck doing the work for others
> > 3. It is easier to 'train' people to do things the same way (ie if maintainers 'do it differently', it makes it harder because it's "do as I say, not do as I do")
> > 4. It saves the OASIS branches for 'real' need for branches (eg we want to keep two versions going simultaneously) which should be much more rare
> > I will concede up front that many TC's do have maintainers do their work in branches while non-maintainers in those TC's do it fork &pull. It's been my experience that there is less participation by 'the rank and file' in those TC's. And having spent over 30 years managing software teams, IMHO my proposal is more 'standard' (and yes I agree others might disagree and claim their way is standard also).
> >
> > I won't fall on my sword over it but I do feel fairly strongly about it.
> >
> > Discussion and counter-arguments welcome.
> >
> > Maybe it could be discussed at next meeting?
> >
> >
> >
> > ------------------------------
> > Duncan Sparrell [...]
>
> I do have completely opposite experiences and see no relation to
> democracy with having maintainers prepare work in branches and then
> have pull requests between branches. This eases the work culture
> a lot and reduces the load on the maintainers.
> Maintainers always do the work of others, that is the clear
> definition of the role. No need to save branches. Editors will
> create editor revision branches for say monthly revisions
> anyway.
>
> Can we please focus on the actual technical work of evolving
> a specification collaborativerly and in the spirit of the
> contributed work from the data and trust alliance?
>
> I currently perceive being kept busy with
>
> - avoiding a specific mono-cultural way of information modeling
> - discussions on titles when we do not have a first content version done
> - now and before procedural questions thrown into the mix which
> are not posed by current practice
> - busy waiting on an XML schema contribution that never arrived
> - OASIS links that lost thei public accessibility
> - discussions on naming folders
>
> I would love to instead collaboratively edit the core specification.
>
> Thanks.
>
> /Stefan. [...]
Cheers,
Stefan.
Original Message:
Sent: 5/30/2025 12:01:00 PM
From: David Kemp
Subject: RE: GItHub Branch/Fork Process for DPS
Here is one summary from StackOverflow:
Forking
Pros
· Keeps branches separated by user
· Reduces clutter in the primary repository
· Your team process reflects the external contributor process
Cons
· Makes it more difficult to see all of the branches that are active (or inactive, for that matter)
· Collaborating on a branch is trickier (the fork owner needs to add the person as a collaborator)
· You need to understand the concept of multiple remotes in Git
· Requires additional mental bookkeeping
· This will make the workflow more difficult for people who aren't super comfortable with Git
Branching
Pros
· Keeps all of the work being done around a project in one place
· All collaborators can push to the same branch to collaborate on it
· There's only one Git remote to deal with
Cons
· Branches that get abandoned can pile up more easily
· Your team contribution process doesn't match the external contributor process
· You need to add team members as contributors before they can branch
I think there is a difference between collaborative software development and standards development: in our case maintainers are not autonomous actors, they have a fiduciary duty to reflect the OASIS open consensus process using explicit ballots and lazy consensus. For that reason I don't find the pro-Branching "All collaborators can push to the same branch to collaborate on it" convincing. I view it as a disadvantage because it requires contributors to be repo maintainers, which IMO is a risky elimination of guardrails.
I find it comforting to own my own fork where I can do anything including screwing up (which I have done) without any danger to the TC repo. Many TC members are not super familiar with using git and might appreciate the same freedom to work in their own sandbox with guardrails, making them more likely to contribute directly via GitHub rather than submitting ideas via email that have to be interpreted by maintainers.
So I SECOND the fork-and-PR proposal, and observe that we'll need a ballot since we don't have lazy consensus.
David
Original Message:
Sent: 5/28/2025 4:39:00 PM
From: Stefan Hagen
Subject: RE: GItHub Branch/Fork Process for DPS
Hi,
On Wed, May 28, 2025, at 17:51, Duncan Sparrell via OASIS wrote:
> I don't want to start an argument akin to the vi/emacs religious war, but I will anyway because I prefer the more democratic branch process for this TC.
>
> I would propose that everyone (ie including maintainers) use the fork&pull process. Maintainers are "allowed" to make their own branches on the OASIS account repo (and they have done so), but most of the membership is not allowed to. Most members need to fork&pull. I propose maintainers also fork&pull instead of creating branches on the OASIS repo. My reasoning is:
>
> 1. IMHO we'll get more participation based on my previous experience with several other TC's and in managing large software teams.
> 2. Maintainers won't get stuck doing the work for others
> 3. It is easier to 'train' people to do things the same way (ie if maintainers 'do it differently', it makes it harder because it's "do as I say, not do as I do")
> 4. It saves the OASIS branches for 'real' need for branches (eg we want to keep two versions going simultaneously) which should be much more rare
> I will concede up front that many TC's do have maintainers do their work in branches while non-maintainers in those TC's do it fork &pull. It's been my experience that there is less participation by 'the rank and file' in those TC's. And having spent over 30 years managing software teams, IMHO my proposal is more 'standard' (and yes I agree others might disagree and claim their way is standard also).
>
> I won't fall on my sword over it but I do feel fairly strongly about it.
>
> Discussion and counter-arguments welcome.
>
> Maybe it could be discussed at next meeting?
>
>
>
> ------------------------------
> Duncan Sparrell [...]
I do have completely opposite experiences and see no relation to
democracy with having maintainers prepare work in branches and then
have pull requests between branches. This eases the work culture
a lot and reduces the load on the maintainers.
Maintainers always do the work of others, that is the clear
definition of the role. No need to save branches. Editors will
create editor revision branches for say monthly revisions
anyway.
Can we please focus on the actual technical work of evolving
a specification collaborativerly and in the spirit of the
contributed work from the data and trust alliance?
I currently perceive being kept busy with
- avoiding a specific mono-cultural way of information modeling
- discussions on titles when we do not have a first content version done
- now and before procedural questions thrown into the mix which
are not posed by current practice
- busy waiting on an XML schema contribution that never arrived
- OASIS links that lost thei public accessibility
- discussions on naming folders
I would love to instead collaboratively edit the core specification.
Thanks.
/Stefan.
Original Message:
Sent: 5/28/2025 11:51:00 AM
From: Duncan Sparrell
Subject: GItHub Branch/Fork Process for DPS
I don't want to start an argument akin to the vi/emacs religious war, but I will anyway because I prefer the more democratic branch process for this TC.
I would propose that everyone (ie including maintainers) use the fork&pull process. Maintainers are "allowed" to make their own branches on the OASIS account repo (and they have done so), but most of the membership is not allowed to. Most members need to fork&pull. I propose maintainers also fork&pull instead of creating branches on the OASIS repo. My reasoning is:
- IMHO we'll get more participation based on my previous experience with several other TC's and in managing large software teams.
- Maintainers won't get stuck doing the work for others
- It is easier to 'train' people to do things the same way (ie if maintainers 'do it differently', it makes it harder because it's "do as I say, not do as I do")
- It saves the OASIS branches for 'real' need for branches (eg we want to keep two versions going simultaneously) which should be much more rare
I will concede up front that many TC's do have maintainers do their work in branches while non-maintainers in those TC's do it fork &pull. It's been my experience that there is less participation by 'the rank and file' in those TC's. And having spent over 30 years managing software teams, IMHO my proposal is more 'standard' (and yes I agree others might disagree and claim their way is standard also).
I won't fall on my sword over it but I do feel fairly strongly about it.
Discussion and counter-arguments welcome.
Maybe it could be discussed at next meeting?
------------------------------
Duncan Sparrell
Chief Cyber Curmudgeion
sFractal Consulting LLC
Oakton VA
703-828-8646
------------------------------
</https:>