Tim and Nate: could you please review the document? The latest version is available at this link:

https://dmtn-027.lsst.io/v/DM-7957/index.html

Nate: I stole what you'd written for Perry Gee in the other ticket and fleshed it out a bit. Please let me know if I said anything incorrect in the "Merging in work" section.

Looks great. This is really helpful. Minor comments:

• Add link to RFC process in developer guide when mentioning RFC.
• In the updating lsstsw repos.yaml section link to the dev guide where we talk about that.
• In "Update dependent packages" they need to update the ups/xxx.cfg files as well.
• Merging in work section: Missed a pipe_best code markup in bullet 3. Also the rst reference is unresolved later in #3.

I'll let Nate Pease [X] mark the ticket reviewed when he is done.

I've updated based on Tim's comment above, plus a significant rewrite of the "merging work" section.

Overall the doc looks very good. I think there is one process point to address, and if people agree with it then I think it should make its way into the document:

Before the fork to pipe_best happens, developers with work in progress should have a chance to push any local changes in their branches to meas_worst, so that their branches will also exist in pipe_best after the fork.
(one of the reasons it ended up being easy for me to integrate my changes was that I had pushed all my branches to daf_butlerUtils before leaving for vacation, before the fork to obs_base happened).
The person who will do the rename should find developers with work in progress (I put details about how to do that below) and work out a time to do the change, giving them a chance to push all their latest work

This is a subtle difference from our normal workflow where I've heard it put: "first to master wins", which is ok by me given the usual caveats about publishing API changes and doing RFC's and whatnot. The difference in this case is that other devs should be allowed the chance to send all the latest work in their branches along with the fork.

I think there's 2 ways I know of to figure out who may have work in progress:

The first is to look for active branches on github:
1. go to the package home page on github
2. click on the 'code' tab (if needed, I think it's the default tab)
3. click on the sub tab that shows the number of branches e.g. it will say something like "101 branches"
4. click on the 'active' tab to see active branches and who owns them.

The other way is to search for the component in lira:
search for issues with status "in progress" and where the component matches the package name

If we adopt this process, then the section "Merging in work that had started on the old package" changes to
1. Before meas_worst is forked, push your meas_worst changes to github on your branch.
2. After the rename is complete, clone pipe_best: git clone https://github.com/lsst-dm/pipe_best (it would also work to instead do 'rebuild pipe_best', which will clone pipe_best into the 'lsstsw/build' directory)
3. Checkout your branch; it should exist in pipe_best. If it does not, or if it is not up-to-date with your latest changes in meas_worst, you may have to follow the `syncing a fork`_ instructions.
4. Rebase to pipe_best master: git rebase master
5. Fix any conflicts. There may be a few, if you modified lines around statements that were changed during the rename.
6. Commit and push your branch to pipe_best, and continue your work.

Asking people to push work in progress is good and should be explicit, but you can't guarantee you'll catch everyone (they might be on vacation) so you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.

I guess I should leave this as 'in review' while we decide this point.

you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.

I was lucky enough to not have to deal with that. Perry Gee, did you use git to recover your not-pushed branch? Can you write something up about that for the tech note?

I'll add something about trying to get the attention of other developers with work in branches, but I'm confused about your comment here:

you still have to include instructions on how to recover if the fork happened and the branch was out of date on github beforehand.

I was lucky enough to not have to deal with that. Perry Gee, did you use git to recover your not-pushed branch? Can you write something up about that for the tech note?

There's a whole section of the document devoted to this topic, with step-by-step instructions.

There's a whole section of the document devoted to this topic, with step-by-step instructions.

Oh, of course there it is. (I clearly need a second cup of coffee). So: sorry, and never mind about that part.

I've added a section about developer coordination. Please take a look and tell me what you think. I also tweaked a bit of the text to clarify whether something was to be done on github or on the local clone.

https://dmtn-027.lsst.io/v/DM-7957/index.html#coordinating-with-other-developers
https://github.com/lsst-dm/dmtn-027/pull/2/commits/0bbdd4838944c82c2a64e3998f198fe85f62dfd0

looks great. thanks for writing that up. setting to 'reviewed'

Thank you for the review comments. It's a stronger document for it. This is now live!

https://dmtn-027.lsst.io/