Giter Club home page Giter Club logo

Comments (13)

paradox-tt avatar paradox-tt commented on June 6, 2024 1

Hi Coin,

Thanks for carrying over the discussion to a forum for developer discussion.

I would like to take a stab at rephrasing "the problem".

It is common for child bounties to be awarded in one batch that incorporates four extrinsics or multiples thereof:

  1. addChildBounty(ParentBountyID, Value, Description)
  2. proposeCurator(ParentBountyID, ChildBountyID, Curator, Fee)
  3. acceptCurator(ParentBountyID, ChildBountyID)
  4. awardChildBounty(ParentBountyID, ChildBountyID, Beneficiary)

While most input parameters are known at the time of execution, the child bounty ID is taken predictively. Most bounties are curated by multi-sig accounts and delays with approvals permit other curators to execute similar transactions which invalidate the predicted child bounty IDs.

This is more a matter of convenience more that it is a system issue. One could...

  1. Issue a batch of addChildBounty(...)
  2. When it is executed collect the certain child bounty IDs
  3. Execute proposeCurator, acceptCurator and awardChildBounty using the established IDs.

This would take require two requests for approvals but it would lend to expected execution.

With no offense intended, I do not like your proposed solution for the following reasons:

  • Keeping track of the counts for each child bounty using int representation would be cumbersome. A proper implementation would best utilize a map with a counter for each bounty.
  • Taken per example, it imposes a limit on the number of child bounties of 9999
  • We can debate padding scenarios but this is NOT ideal and can lead to allocative inefficiencies i.e. batches of numbers with no use.

With that said, I disagree that the issue of convenience surrounds the common child bounty index but rather the lack of an atomic extrinsic to achieve steps 1-4.

My humble suggestion, create a single extrinsic that executes steps 1-2 without the need for entering a child bounty ID such that the child bounty id generated by 1 lends into 2. Allow further execution of 3 and 4 if the child bounty curator is the signer.

I hope this brings clarity to the matter but I would love to hear the take of the core-devs for my own development.

Regards,
Will | Paradox

from substrate.

CoinStudioDOT avatar CoinStudioDOT commented on June 6, 2024 1

Dear Will | Paradox,

Firstly, I want to express my sincere appreciation for the time and effort in rewriting the post and providing your perspective on this issue.

However, this seems to be same misunderstanding of the problem as previously explained in the forum post.

The challenge here relates to multisig transactions that remain pending over several days, NOT the process of child bounty ID allocation itself. In a perfect scenario multisig acting as a 'lazy consensus' mechanism, should be able to take as long as needed to reach consensus, free of time restrictions. However, our current ChildBounty ID restrictions pose a challenge to this laid-back approach, demanding a quick multisig executions.

This would take require two requests for approvals but it would lend to expected execution.

Your approach is thoughtful but it appears to add an extra layer of complexity to the problem without addressing the problem core. The problem lies in the ID interference caused by delayed multisig approvals. Splitting the batchcall extrinsic into a few steps is not solving the multisig time issue. The proposition we are discussing here aims to evolve this process. Instead of relying on these โ€˜quick fixesโ€™, we want to create a system where each bounty operates independently of others, eliminating the risk of ChildBounty ID overlap.

What we're trying to achieve is an environment where each bounty operates independently, without dependency on the progression or status of others. The proposed 8-digit solution was suggested with this goal in mind - to eliminate dependencies and ensure that the child bounty ID allocation process is uniquely tied to each individual bounty. I am interested to hear in any variations of this solution. 8-digit ID solution is a proposed option that we can start from.

Your concerns regarding the limitation on the number of child bounties and potential inefficiencies are duly noted and appreciated. However, this has a very low impact as it is not likely that a single Bounty will issue more than 9999 child bounties. Even if this become the case, a proposer can open a new Bounty and start issuing child bounties from 1 (relative to the new ID xxxx0001).

Just to clarify, the proposal on the table is NOT suggesting using the current child bounty ID system, but rather to introduce a new unique identifier. This unique ID would be a combination of the parent bounty ID and the child bounty ID (proposed solution), allowing each bounty to function independently and eliminating the current dependencies.

Once again, I'd like to express my gratitude for your valuable contributions to this discussion. I would really love to hear from the core devs to hear their take on possible implementations.

On a side note, a similar issue was opened by @annaelleparity paritytech/polkadot-sdk#591 that I didn't pick in the first place.

from substrate.

anaelleparity avatar anaelleparity commented on June 6, 2024 1

Thank you for bringing this issue up, @CoinStudioDOT.

From my perspective, it is pretty clear that the current indexing system for childbounties is rather inefficient and cumbersome for those involved in bounty curation, as well as obscure and arbitrary for those who aren't.

When designing systems that are meant to be used by decentralised communities, it is important to reduce unnecessary complexity as much as possible and support transparent operations.

Updating the current Childbountied ID system would only be the first step in the process of making bounty curation more manageable for curators and more approachable for the general community; but it is a critical one.

Thank you to @paradox-tt for being so reactive and committed to proposing alternative arrangements. I am hoping that more propositions will follow up in time, so that we can address this issue in practice sooner rather than later.

Thank you! ๐Ÿ™

from substrate.

anaelleparity avatar anaelleparity commented on June 6, 2024 1

Hi @paradox-tt,

I think you might have taken my statement re: "updating the current Childbounties ID system" a bit too literally, meanwhile I am discussing the big picture at play here.

I am interested in any proposal that solves the issues I have described here, including making it easier for non-tech folks to navigate bounties and childbounties and pull out meaningful data. From what I know, this touches upon many different areas of dapp development such as UX and UI, not just programming.

I am certainly not in a position to decide unilaterally what works for everybody and push for its immediate implementation. And this is why I wrote that I was hoping we would get more input from the community at large and devise more engaging alternatives together.

Thanks for your time.

from substrate.

Polkadot-Forum avatar Polkadot-Forum commented on June 6, 2024

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/improving-childbounty-id-allocation-an-8-digit-solution-proposal/3566/14

from substrate.

paradox-tt avatar paradox-tt commented on June 6, 2024

What more can I say...

The solution I'm proposing is a single extrinsic that would generate the child bounty ID upon execution (after all multi-sig approvals are obtained). It would then feed the child bounty index into the other functions that are commonly batched with the call. It is independent of approval time.

from substrate.

CoinStudioDOT avatar CoinStudioDOT commented on June 6, 2024

I see several advantages to the approach of assigning separate, unique IDs to each bounty, as Annaele suggested.

-Having a separate system for Childbounties IDs tied to their parent bounty ID would help curators and the community gain a better overview of childbounties-related data (i.e how many, for which bounty, how often, recurrent implementers profiles/recurring beneficiaries, etc.)

We are all here with a common goal - to make our processes as efficient and user-friendly as possible. As such, suggestions for simplicity are always welcomed as the assembly of multiple child bounties and related extrinsic can at times be quite cumbersome. Having said that, I believe that auto-generation of childbounty IDs could help curators eliminating the need of searching for the first available child IDs.

from substrate.

paradox-tt avatar paradox-tt commented on June 6, 2024

Hi @anaelleparity and @CoinStudioDOT

I respect that your perspective is non-technical; I'm also trying my best to appreciate why you're adamant towards this 8 Digit solution when I've proposed a more efficient solution which:

  1. Introduces no new storage variables to the runtime
  2. Doesn't require a user to understand a proposed convention of child bounty IDs
  3. Brings about the desired outcome even when approval is delayed (Multi-sig approval scenario)

What I've suggested means that you don't need to interact with child bounty IDs at all.. may I ask why do you think you NEED to interact with it? Maybe if I understand your pain points, I can have a better appreciation of your point of view.

from substrate.

CoinStudioDOT avatar CoinStudioDOT commented on June 6, 2024

Hey @paradox-tt

I appreciate your active participation and the perspective you bring to this discussion.

I have opened an issue to address the particular problem of delayed multi-signature transactions and to introduce a more sustainable system for tracking bounties and child bounties as mentioned in the posts above.

The proposed new 8-digit ID is an illustrative example of a solution for the core developers to assess the situation and see the best possible implementation of such. The goal of this topic is to open dialogue and find the most effective and efficient solution to the problem at hand. In that spirit, all suggestions are warmly welcomed and carefully considered including yours. The final decision and choice of how the problem will be solved should lie with the parity cor dev who will work on the issue.

I want to ask you to keep the conversation open and respectful rather than calling other solutions a non-technical perspective and approaching the conversation by saying my solution is more efficient. In stating this, I intend no offense, merely a reminder of our shared objective. We're all here with a common purpose: to collaboratively solve problems and advance our project. Let's continue to work together in a spirit of mutual respect and open-mindedness, valuing each contribution. Thank you for your engagement in this process.

from substrate.

paradox-tt avatar paradox-tt commented on June 6, 2024

@CoinStudioDOT I'm sorry that you're offended by the use of non-technical, no offense was intended. An end-user's perspective is also very valuable. I was hoping for a more analytical discussion but it seems we are not coming to a meeting of the minds. I'll hold on responses until said is provided.

from substrate.

CoinStudioDOT avatar CoinStudioDOT commented on June 6, 2024

I appreciate your understanding, @paradox-tt , and rest assured that no offense has been taken. The aim here is indeed an analytical and constructive discussion. Various perspectives often offer invaluable insights in problem-solving. Let's continue the dialogue with this spirit of collaboration and inclusivity. I'm looking forward to further discussions and contributions on this topic.

As previously mentioned, I strongly agree that there's significant room to improve and simplify the current process of required bounty batched calls. Your proposed solution, while not entirely addressing the specific issue we're discussing here, could contribute to simplifying the process of batching calls through the auto-assignment of child IDs. This is something that could be valuable in its own right and should be further explored.

from substrate.

xlc avatar xlc commented on June 6, 2024

Let's focus on the problems that we want to address first before diving too deep into the details.

To clarify, the root problems are

  • Generation of a child bounty is non-deterministic (in the way that you can guess what it could be but cannot guarantee the value before it is created).
  • A common workflow is to perform the creation of child bounty and additional operations (propose curator) in a single batch call from a mutlisig account. Due to the previous point, which process is error-prune.

@CoinStudioDOT 's suggestion is essentially to make the child bounty ID generation is fully deterministic. The exact way can still be discussed as for example 1000 child bounty limit per bounty may or may not be enough. We also need new storage to keep track of the total child bounty count for every bounty.

What @paradox-tt 's suggestion is to solve the second point by merging the batch calls into a single extrinsic that doesn't need the child bounty id. Something like addChildBountyAndPropsoeCurator(ParentBountyID, Value, Description, Curator, Fee). The benefits of this approach is that no storage modification is required.

@CoinStudioDOT could you describe bit more about the current workflow including details like how many calls to execute, the content of each batch call, etc. I am sure your proposal will solve your problem but wanting to check if the other solution is feasible as well. In the end, we want to explore all the possible solutions first before arriving in a decision.

from substrate.

CoinStudioDOT avatar CoinStudioDOT commented on June 6, 2024

Hi @xlc,

Thank you for your input. Your points are correct:

To clarify, the root problems are

  • Generation of a child bounty is non-deterministic (in the way that you can guess what it could be but cannot guarantee the value before it is created).

  • A common workflow is to perform the creation of child bounty and additional operations (propose curator) in a single batch call from a mutlisig account. Due to the previous point, which process is error-prune.

I believe this recent example can better demonstrate the content of the batched calls.

The current workflow is to assign/adjust structured batch calls like in the example above and issue to multisig. After the extrinsic submission, it is a typical case to wait an extended time for multisig to reach the minimum consensus and execute the call.

Due to some complexity on how to effectively track each Bounty payment (childbounty) and have it clear and transparent for a wider community, I believe a ChildBounty IDs is useful in this sense. If there is an effective way to solve this, I am in favor of any solution.

One other thing that came to my mind is the option that during Bounty creation bounties.approveBounty, an option for Bounty to predetermine and reserve a childbounty ID range for future use. This may solve this problem but introduce some other id tracking issues.

Thank you for your time looking at it and looking forward to get the problem solved.

from substrate.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.