How to Handle Complex Breaking Merges for Other Bounty Hunters?

[0x4007]

Hey guys i’m seeking advice on how to handle situations where bountyHunterA pushes a ton of breaking changes to the codebase in the middle of bountyHunterB and bountyHunterC’s bounties, now adding a ton of extra work to their plates.

The reason why I think its a big problem is because I see a future where we may have 10s of PRs/bounties being solved simultaneously. breaking changes will slow everybody down but i think they are unavoidable. Whats the best strategy to handle this?

---

I did an interactive rebase and pushed to https://github.com/ubiquity/ubiquity-dollar/tree/devsupport-org/development

Unfortunately the CI from my interactive rebase seems far from working and I'm not sure of the best solution here other than starting on a clean branch.

On one hand, we technically should have revoked the bounty after week 2 (this is a 1 week bounty) but it seemed like you were making good progress. On the other hand, if we can't figure out how to solve these sort of issues, I think that our decentralized development is going to struggle to scale.

@0xcodercrane this is the exact type of problem I was seeking to avoid when I asked you to look into merging #351

I think we should have an all hands meeting with the other pro devs in our org to get their opinion on how to best solve this type of issue.

Originally posted by @pavlovcik in #313 (comment)

[zgorizzo69]

Here is my 5cents on this .
PR that will have a big impact on the codebase should be done when there are no other work pending or it should be clear for the others that they will have to rebase.
Nonetheless it is common to have to rebase during our development and 80% of the time it is not a big deal neither time consuming.hunters should be well aware of that. It can become unfair if for instance I finished a PR that is rebased and working and we take so long to merge it that I have to rebase after finishing it one month later. So we need to handle review /merging as fast as hunters solve bounties

[0x4007]

PR that will have a big impact on the codebase should be done when there are no other work pending or it should be clear for the others that they will have to rebase.

I don't think this is realistic with the vision of our development team. To clarify, once we have the developer relations managers and bounty-bot functional, I see a near future where we have 10-50 open PRs and developers working simultaneously on solving bounties.

Our goal is to make our development highly scale (with clever incentive design vs manual management) in a distributed manner. If we achieve this design objective then this solution isn't applicable.

hunters should be well aware of that.

Perhaps this is my means of trying to make a more accommodating work environment. We certainly have varying skill levels within our DevPool. The more accessible we can make contributing to our codebase to the less experienced developers, the more talent we will be able to access.

It can become unfair if for instance I finished a PR that is rebased and working and we take so long to merge it that I have to rebase after finishing it one month later.

I aspire to close out bounties and not have bounty hunters be on the hook for them as soon as they are merged!

[zgorizzo69]

It is not clear to me who and when people will review and merge the PRs.

It seems that we should have senior/leader dev to handle a certain amount of devs/work. They 'd have a high level view of what is going on and so the dependencies between tasks + would make sure quality follow our standards along with providing (light) support and writing/updating the bounties

Indeed I would not bet that to build a castle fast hiring 10000 workers and give them the blueprints/tasks to accomplish will be enough to end up with le château de Versailles over a month. IMHO For large endeavour including junior workers other leading roles are required.

[0x4007]

It is not clear to me who and when people will review and merge the PRs.

@ubiquity/bounty-masters will, basically the trusted developers that are familiar with the codebase and whom we work well with.

It seems that we should have senior/leader dev to handle a certain amount of devs/work. They 'd have a high level view of what is going on and so the dependencies between tasks + would make sure quality follow our standards along with providing (light) support and writing/updating the bounties

Bounty Hunters are the base level developers and then eventually they can get promoted to @ubiquity/bounty-masters to act in this role! We are still working on structuring these roles and their incentives more but we're getting pretty far along if you check the features discussion under bounty-bot ubiquity/ubiquibot#1

[ryzhak]

breaking changes will slow everybody down but i think they are unavoidable

+1

we need to handle review /merging as fast as hunters solve bounties

+1

To sum up:

1. Merge conflicts are unavoidable.
2. Do not overoptimize. When there are enough developers in @ubiquity/bounty-masters(who can review/merge PRs) they will review and merge changes pretty fast so there will be very few merging issues.
3. When project is in its early days then "global changes" happen quite often, for example the following:

• ERC-2535 Diamond Implementation #313
• Refactor to reflect current product names #351
  When project is deployed and functional, then it is hard to imagine a feature that will globally update all the contracts or the whole project thus causing merge conflicts for other devs.

[0xcodercrane]

Sorry guys for not answering promptly. It seems like notification issue not solved yet on my end.

1/ Each hunter is responsible for the tasks assigned to him. They don't need to care about other PRs. so the conflicts between the pull requests need to be resolved by @ubiquity/bounty-masters. but each issue should include everything to fix the broken stuff for the whole protocol as well as its new feature. i.e: in case of #351, that issue will absolutely break the UI. so ideally it was fine for that PR to contain fixes which would break the UI (like deploy the new branding contracts on goerli, UI should connect to the new branding contracts deployed, etc --- but it seems we didn't consider when merging it which is absolutely my fault)

2/ How could @ubiquity/bounty-masters solve the conflicts between hunters PRs?
We should continue reviewing PRs each time hunters request for review. Its not a problem. but we should temporarily pause merging if it breaks other PR even though its completed. We need to discuss which PR needs to be merged for first, which PR for next, etc.
Once it's clear via a discussion, we can merge one by one but should absolutely resolve conflicts. For the PRs which are still in progress, bounty-hunters should merge development branch to their working repositories/branches and solve conflicts. Once all the conflicts have been resolved, we can ask a hunter to continue contributing. In that way, hunters will not lose their energy on their contributions. this is just my opinion.

[0x4007]

I don't get reliable notifications on discussions either. I have to check once in a while manually.