This history follows the interations between four people who worked together to update two IVOA repositories. All the interaction were via GitHub comments and notification emails.

To update the ivoatex-docker project the Zarquan created an issue in the ivoa/ivoatex-docker repository.
"Update to latest versions"

Zarquan created zir own fork of the ivoa/ivoatex-docker repository and worked on the code.

Zarquan made the changes in zir fork and then created a pull request in the main ivoa/ivoatex-docker repository.
"Updated to use Ubuntu 21.10"

Zarquan asked Sara to review the changes, which meant Sara needed to be given write access to the ivoa/ivoatex-docker repository. Easiest way to do that was to add Sara to the ivoa/developers team.

Sara completed zir review and added a comment about a problem building the SSO document.
"... I have an error building the bibliography of the SSO"

Markus saw Sara's comment in an email notification and suggested a fix.
"... these were legacy entries in the old bibliography which we've removed ..."
"... use 2010ivoa.rept.1123A instead of note:VOARCH and 2018ivoa.spec.0625P instead of std:VOR"

Zarquan created an issue in the ivoa-std/SSO project

and created zir fork of the ivoa-std/SSO repository to work on the fix.

Zarquan made the changes to fix the issue in zir own fork and then created a pull request in the ivoa-std/SSO repository.
"Issue 2 fix biblio"

Zarquan may have write permissions on the ivoa-std/SSO repository but ze was not able to merge zir pull request until it had been reviewd by someone else.

Marco saw Zarquan's pull request in an email notification and approved the changes.
"Looks fine to me. Approved."

Once Marco had apporved the changes Zarquan was then able to merge zir changes into the ivoa-std/SSO repository.

Marco was able to see why the changes were being made because the description of the pull request referred back to the issue in ivoa-std/SSO =>

and the description of the issue in ivoa-std/SSO referred to Markus's comment in the discussion about the ivoa/ivoatex-docker pull request. =>

Zarquan added a comment to zir pull request in the ivoa/ivoatex-docker repository letting Sara know that the issue had been fixed in the ivoa-std/SSO repository.
"@bertocco Hi Sara - the issues with the biblio codes in the SSO dcoument have been fixed. Could you re-test this for me."

Sara continued zir review and added a comment about an unnecessary step in the README file.
"When you run the container using podman, youenter directly in the /document path, you don't need the cd document command mentioned in the README"

Zarquan removed the unnecessary step from the README file in zir fork, Zarquan/ivoatex-docker.

Sara added a comment about the odd user name when run from Docker.

    groups: cannot find name for group ID 1000
    I have no name!

Zarquan added an issue about the user name and group.
"Fix the empty user name when run in Docker"

Sara approved the pull request and merged the changes, choosing the option to squash the chain of small commits into one step.

Four people worked on two IVOA repositories in this process, interacting via emails and comments in GitHub.

* Sara * Markus * Marco * Zarquan

* *

Zarquan created zir own forks of the IVOA repositories,

* *

but Sara, Marco and Markus only interacted with the main IVOA repositories.

Zarquan made two sets of changes, one set of changes on an issue-specific branch[]]

and the other set of changes to the master branch of zir fork.

Both worked, although creating an issue specific branch is probably better if the user intends to make a number of changes to the same project.

Given that the branch is created in the users own fork, I'm not convinced we need to require the branch names to follow a specific syntax.

The branch name does not carry over into the upstream repository when the merge is done, so users should be free to name their branches in a way that makes sense to them.

Adding the issue number to a branch in the users fork can be odd because the issue number refers to an issue in the main repository, not in the users own repository.

I think restricting write permissions on the main ivoa-std projects to working group chairs, tcg members and document editors is the right level of access control.

Everyone else is free to create their own forks of the ivoa-std repositories and propose changes via pull requests.

If a group of users want to work together on a set of changes, they can create a fork in one of their own accounts and work on the changes there. The owner of the fork granting write access to their fork as needed. When the group are happy with the changes, they can propose them as a single pull request to the main ivoa-std repository for review and merging by the ivoa-std editors.

In this example Sara needed to have write permissions for the ivoa/ivoatex-docker repository in order to be able to review and merge Zarquan's pull request.

That makes sense because Zarquan and Sara are developers working together on a software development project. However, I don't think either Zarquan or Sara needed to have write permissions on the main ivoa-std/SSO project.

It was easy enough for Marco to step in and approved the changes in Zarquan's pull request, and it would be an extra button click for Marco to have merged Zarquan's changes as well.

This document was written using the ze\zir pronouns[]].

Topic revision: r1 - 2021-07-21 - DaveMorris
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback