Ten Best Merge

Wiki takes some inspiration from github but is happy to diverge when it comes to refactoring. Here we imagine Portland foodies sharing and merging their rankings of the ten best sushi restaurants.

First we assume that the foodies know each other, start walking from the same place, and agree that there are exactly ten sushi restaurants in contention.

This is an example of a refactoring problem which includes an element of judgement and preference. Our goal is to find the best restaurants, not the correct restaurants.

# Git

One foodie creates a new file in the foodie repo named best-sushi-in-order.md with names and addresses in alphabetical order.

The remaining foodies are challenged to put that list in proper order and issue pull requests to merge their changes.

# Wiki

One foodie create a new page in his foodie site named Best Sushi in Order with names and addresses in alphabetical order.

The remaining foodies are challenged to put that list in proper order while considering the choices of the other foodies in their common roster.

# Merge

The github repo will not be complete until all of the branches have been merged with all of the conflicts resolved. Discussions of order correctness can appear on any of the pull requests. Perhaps some are recognized as better and merged leaving others to rebase their changes.

The wiki sites will never be incomplete as each one represents one person's considered opinion in the moment. The degree of consideration might be marked with Page Folds for 'best' and 'untried'.

Wiki foodies are encouraged to try every restaurant and update their page upon return.They all start from the same alphabetical list which they retrieve from history when they enter the collaboration.

Wiki foodies see newer pages as twins of their own list. They might choose to try the same restaurants for a second opinion or find the least tried to offer a first assessment. The many-way side-by-side shift-hover comparisons highlight contrasts.

Wiki foodies might add criteria for promotion to the names and addresses they move around. These might be links that explain Best Service, Best Prices, Best for Date, etc. These edits don't interfere with shift-hover comparisons.

# Value

Github vs. Wiki. The workflows differ in what they try to merge. Github pull requests aim toward the one right list, presumably to inform future readers. The wiki workflow informs the foodies of their own diversity and ends with a chorus of opinions. If there were a single winner, that says something, if not, that says something too.

The github exercise may or may not merge to a conclusion. Then what? Restaurants come and go. Who is likely to open another pull request? Who will merge it?

To what end to wiki foodies further maintain their own choices in their own sites? Will it be news to anyone else if rankings change for anyone over the subsequent months and years? Do foodies come and go? Do they continue eating sushi? Yes, I think so.

The faculty of an academic department considering where they might extend research effort could be well served by a wiki chorus. However, when the department starts handing out funding from the general fund, then the github discussion and owner's merge might be a better choice.