@saxemberg 

Thank you for the feedback. Please find our reasoning for the expanded proposal and a suggestion for changing the breakdown below.

We included new features in the proposal in comparison to the initial description of MS2, as the additional ideas came after user feedback and requests.

The proposed Curator UX Improvements task includes features that were expressly requested by users and include features such as end to end automation of child bounty creation, multiple child bounties batch creation, curator signatories salary payouts automation, batch child bounties creation from a file upload and automation of bounty extension. We consider delivering this part of the same, if not higher priority as delivering the originally described milestone 2.

The analytics suite, also conceived after users request, will be a very useful addition to the UX for curators, allowing easier reporting and overview of their bounties. Additionally, as the code will also be open source, it will benefit other tracking tools in the ecosystem such as OG Tracker and Subsquare, who will be able to integrate it directly on their own platforms to display bounty specific analytics.
We consider that this is also of equal priority to the curator actions improvements and the originally described milestone 2 and will have a greater impact on the entire ecosystem.

The integration with Clarys will also be an extremely useful tool for the curators, enabling them to quickly assess the validity of a beneficiary’s application to the bounty, so integrating it to the Bounty Manager UI will save time and effort, using one website as the single touch point for bounty curation. However, since the MVP of the Clarys tool itself will launch in December, it’s understandable that its value needs first to be measured on its own before an integration into other OpenGov products like ours is considered viable and we agree that this part of the proposal will be better suited as a milestone 3 if that is what the OpenGov prefers.

The UI improvement to include a dark/light mode is also a task created after user feedback and we think would be a nice addition, however it’s also completely understandable to us how it could be considered unnecessary at this point and would also be better suited as a milestone 3 component.

Regarding the maintenance costs, we initially didn’t expect it to be so demanding, so we did not calculate them for the initial proposal, however during development we realized there are frequent changes that need to be accounted for. An upcoming update and transition of the bounties pallete into Asset Hub will also require a rework of the product, which is also included in the details of the maintenance paragraph. If you consider it more fair, we can suggest removing the maintenance part from the proposal and including it in a retroactive request at the end of 2025.

Our suggestion would be to restructure the proposals with the following breakdown found below.
We strongly believe that the functionality additions to the curator UX are priority 1 and should be included in the delivery of milestone 2, so we would still leave it in the proposal as is.
We think the analytics suite is of equal priority, however we do not include it in MS2, to avoid overexceeding the budget of the originally proposed.
The other additional features, which will be enhancements and improvements to the product, can be included in a milestone 3 proposal after delivery of MS2, together with the analytics suite.
Finally, we would leave the maintenance budget as a separate referendum to be proposed at the end of 2025.

We welcome feedback from the community and if voters prefer so, we will split the tasks and re-propose the referendum.

The goal with proposing everything in the same referendum was to save time and effort, for both the voters and us, by avoiding the voting process of multiple proposals.
In retrospect we should have communicated this clearly before creating the proposal and gotten the confirmation of stakeholders in the ecosystem on if this is acceptable.

@RotkoNetworks We will open source the repository in the next two to three weeks as it was our intention and promise from the beginning.
It will be available with the Apache 2.0 license for anyone in the ecosystem to integrate and use.

We apologize for the issue with bountymanager.io not loading, it was caused by an issue with the node connection, which has been fixed already now.

The maintenance costs have been calculated for an entire year of operation, and as described in the details, it includes the estimation for an expected required rework, for updates to the bounties pallete and migration to assethub in Q1 2025.

We hope this answers your concerns, and we are always open for feedback and further questions.

looks like we hold a bit hostage here. initial work was never done as open source initiative so regardless of treausry paying a lot for this work we did not actually receive anything for the money.

well at least i did not find a way how to run this code myself and code that you publis at bountymanager.io keeps loading forever.

maintenance cost seems absolutely outrageous so i guess its best to cut our losses here than continue to pay for something we dont own or are allowed to use.

Our intention with OpenGov is to more or less maintain the self-imposed milestones that were agreed upon on the previously approved referendum. For this referendum, the milestone #2 was supposed to cost 59600€ but it costs 265k$ (250.51€).

Milestone 2 is more expensive than milestone 1 despite being expected to cost a fraction of it. The additional cost of maintenance 49120€ befalls on the previously approved referendum voters so for that reason we as voters will have to take the responsibility to inquire about future operating costs because this was not presented explicitly for milestone 2, we’ll do it more heavily starting now. The remaining 141.28€ of “new features” is something we really cannot justify at the moment specially the UX and UI improvements specially when milestone 2 has not been delivered just yet.

In addition, we hope that in the future new costs and features are presented as separate referenda so that we can decide on them without having them bundled with the expected costs.

This comment will remain as a precedent for the basis of future votes, including referendum 1325 which has not been cast yet.

It would help the decision process in this referendum if the curators actively using this tool provided feedback or publicly vouched for its utility and impact.

@BRA Apologies Bryan, the document is already open now

please open the doc to everybody it´s open gov.....