search

SNL-WaterPower / WecOptTool-MATLAB

WEC Design Optimization Toolbox
GNU General Public License v3.0
12 stars 9 forks source link

Create New Organisation for Collaborative Development #192

Closed H0R5E closed 3 years ago

H0R5E commented 3 years ago

Hi,

I was thinking about this issue with collaborating on PRs that are based on branches from forks in our personal accounts. It's just about manageable for a small dev team like ours, but for WEC-Sim (who are looking to move to a PR based approach) it might be too cumbersome. I have had an idea that might simplify things and I was wondering if we could trial it on WecOptTool?

The idea is simply to create a new Github organisation to hold development forks, to which we would all be members. So maybe with a name like "SNL-WaterPower-Team". We can then create a fork of WecOptTool in this organisation and use it for branches to collaborate on for PRs against the main repo. What do you think?

Mat

Tagging @kmruehl, who might be interested in this.

ssolson commented 3 years ago

Mat how much will this change my current workflow? E.g. 1) Push feature branch to ssolson fork 2) Create PR on WecOptTool master (notice how few steps and easy this is, I really don't see how this is cumbersome once you learn it.)

I guess pulling someone else's PR would be the hard part of the workflow: 1) Navigate to WecOptTool PRs 2) Find the fork/ branch the PR is hosted on a) If ssolson local does not have a remote to this fork create one now b) pull remote branch to the local feature branch 3) Make edits 4) Either push directly to PR branch or push to ssolson feature branch and create a PR against remote feature branch

So would your proposal change this process?

H0R5E commented 3 years ago

So I guess one of the primary advantages of the proposed approach is not requiring each developer to authorise all of the other developers to be able work on their personal forks. If there was a dedicated organisation then they just need to be authorised by the organisation owner. This only really pertains to PRs on which you wish to collaborate. If you didn't need to, then there is no reason not to use your local fork, as we do currently.

Regarding workflow for creating a PR, it would be similar (assuming you are a member of the SNL-WaterPower-Team organisation). So:

  1. Push local feature branch to SNL-WaterPower-Team/WecOptTool fork
  2. Create PR against SNL-WaterPower/WecOptTool master branch

Working on someone else's branch would be similar too (if not more simple):

  1. Navigate to SNL-WaterPower/WecOptTool PRs
  2. Find the branch the PR is hosted on SNL-WaterPower-Team/WecOptTool
  3. Pull remote branch to the local feature branch
  4. Make edits
  5. Either push directly to PR branch or push to ssolson feature branch and create a PR against SNL-WaterPower-Team/WecOptTool feature branch.

Note in the workflow you presented for working on someone else's PR, 4 needs permission from the fork owner to push directly to that branch, which is not guaranteed. You can make a PR against the other fork, as you suggest, but perhaps this is less efficient than some might like. This would be our only route to collaborating if we hadn't granted access to each others forks.

kmruehl commented 3 years ago

@H0R5E and @ssolson Thanks for tagging my in this discussion. I also have a few thoughts on the subject.

I think a fork based workflow is great when one person wants to make changes to the main repository. However, as Mat pointed out, it gets more complicated when someone submits a PR from their fork and someone else want to make revisions to the PR. This requires the PR submitter to allow another person to make commits to their fork. I see two other options around this:

  1. If one person is developing a feature, submit a PR to merge into a feature_branch on the main repository (instead of master). That way the team can collaborate on revisions together, and then merge into master when it's ready
  2. If you know a that a feature is going to be developed by a group of people (not just one person), you could do development on a feature_branch to start.

An issue I have with a fork based workflow is that development is done on many disparate forks, which makes development difficult to track. Personally, I like the idea of doing individual development on a fork, but having collaborative development on a feature_branch in the main repository. The two options I listed are in alignment with this suggestions, and differ only in how the work is initiated, e.g. whether it's initiated by an individual or the team.

ryancoe commented 3 years ago

I'm happy with our workflow on this project, but will be curious to see how this goes on other projects

H0R5E commented 3 years ago

@kmruehl thanks for your input. I touched on some of these issues in our WEC-Sim meeting, but I will just maybe reiterate my opinion on these approaches you suggested:

  1. If one person is developing a feature, submit a PR to merge into a feature_branch on the main repository (instead of master). That way the team can collaborate on revisions together, and then merge into master when it's ready

I think you are describing having a number of feature branches open in the main repo to which PRs are made. I think this can work, but there is a risk that some of these branches can get significantly out of date or diverse from each other that it can be quite difficult to merge them all together again. My preference is to a single development branch, which would typically be the master branch, with an understanding that it might be broken sometimes. This is why releases exist, to point to tags in the master branch that are stable.

  1. If you know a that a feature is going to be developed by a group of people (not just one person), you could do development on a feature_branch to start.

I'm of the opinion that this is a bad idea as it implies direct pushing to the main repo, which is risky for reasons such as uploading large files by accident (which will then pollute the history).

An issue I have with a fork based workflow is that development is done on many disparate forks, which makes development difficult to track. Personally, I like the idea of doing individual development on a fork, but having collaborative development on a feature_branch in the main repository. The two options I listed are in alignment with this suggestions, and differ only in how the work is initiated, e.g. whether it's initiated by an individual or the team.

I think the proposal I made in this issue is a halfway house here. With feature branching on the main repo, the repo owner must get involved to create the feature branch first, which adds additional administrative burden. On a fork in a "Team" organisation, anyone could create a branch without concern with doing any "harm" to the main repo, i.e. safe and easy and anyone in the team could work on that branch (as long as @ssolson says it's OK).