One question is circling around for me out of curiosity. How and who decides in the project what is a ‘nice to have’ and ‘need to have’? Given there is a user pain here.
This is always messy with decentralized governance. People like to believe there are no hierarchies, but it’s impossible especially in the beginning stages to not have some sense of direction on matters like this from the core team. Otherwise, we are passing BIP proposals left and right that have no realistic chance of coming to fruition because development doesn’t have the capacity to complete them.
We haven’t heard a lot of developer voices on this subject nor technical analysis, which gives you perspective on their current focus. We really need to flesh this out in the technical sense before it can go to a vote, even if the idea is one we all agree has value.
A BIP passing with a flaw in its implementation is worse than a desired BIP not passing at all.
I co-founded a quickly successful company (we did $80m gross in our first year)… a huge part of that success was the fact that, as developers, we communicated with our customers and we took their input as a priority list for features. One time, I implemented a super simple feature request, while at dinner with the customer as I was talking to them. That one person was blown away and went on to do millions with us.
What I’m saying is that you’ve got a BIP here where 90% of 52 people would like some action in this area. At my company, we only had to have one person to convince us and I’m 100% sure that our attention to these details, was a huge part of our success.
I understand that there is a lot of things going on, but sometimes it makes sense to reprioritize things for the long-term betterment of the project. Task someone with figuring out how to make this happen, if they do it successfully with lots of tests added, awesome, if not at least they tried. The financial resources are there to make it happen and the long-term outcome could be in the millions for the project as a whole.
A set of radio buttons with 50/50 or 100 as the chosen values doesn’t seem like a radically difficult task. Heck, I wish it was 100% from the start as it would have just let people pull out if they want to while reinvesting the rest by default.
Thanks for reading.
I hear people asking ‘when DIGG’ everyday in the Discord. Not when ‘autocompounded Badger Sett’. The biggest financial and technical hurdle on developers’ plates right now is DIGG. I believe that’s the appropriate focus at this time, especially if we’re going to bring up revenue.
Badger Sett has a competitive APY and functions great. I’m depositing more soon myself. Launching a successful new product, to me, is more important than straining development trying to fix something that already works.
The solution to the question of who wants it more is a Snap.
I posit that the loudest are not necessarily those with the most at stake.
I shall also repeat, this isn’t an either / or technical challenge. Both can be accomplished in parallel. This organization needs to be able to do more than one thing at a time in order to have long-term viability.
To be fair, the people asking this are not people you see in the Discord on a regular basis. These are people likely waiting for the drop to sell and move on.
While I don’t think the current devs should realocate their time to autostaking, perhaps we could have it posted on the job board for some new talent to take a look at this.
Imagine if we hired ‘justsomeguy’ to work on our smart contracts…
This play on words also has a point, but I think I’ve made mine for now. Looking forward to hearing more developer voices and technical analysis on this BIP.
The comments here have nothing to do with ‘just hiring someone random off the street’… all we are suggesting is that you start looking. There is no demand to do this tomorrow, just to do it in parallel.
As for the discord comment you made, I had another thought on that. You’ve got a BIP here, with votes, that should be your precedence over loud comments on discord. You have 62 people + 94% yes (which has gone up overnight).
yea it seems like the mods on discord don’t look at the forum
Well you naturally and this issue has just become a need to have. The question to me is now only ‘how need to have’.
I’d argue though that nobody would contest that pushing DIGG and have it walk on it’s own is the no1 need to have at this moment towards which we should dedicate available resources.
On the other hand, seeing how this BIP has reached quorum and a pretty large support, I’d ask if it’s okay with everyone if
-
there could be a timeline amended and we then pass it on snapshot (i’d say a timeline in terms of ‘after DIGG is out and no fires to be extinguished’- probably formulated a bit more professional tho )
-
we’ll keep it here until that moment and then pass it on snapshot.
Honestly I don’t know what’s better, to me both solutions are valid, and in any case, that’s really just my 2 cents on the matter.
Just to show that this really was something that has been on our to-do for a while, I’ll attach this
I am voting for auto-investing as it adds to the seamless experience everyone craves.
My question. Are there potentially any security drawbacks doing this?
I’d like to emphasize the requirements from the About the BIP | Badger Improvement Proposals category.
BIP 18 does not fulfill the full details required of a BIP as it does not include the business or technical requirements of the implementation of the proposal. (e.g. Business = benefits, costs, risks; Technical = scoping, effort, estimate time, technical risk). For that reason, we are not pushing this to snapshot at this time. However, we hear everyone and think this is a good feature for our smaller portfolios and for many of our users. In all transparency, as I mentioned above, we are currently focused on DIGG and designing future products but will see if one of our devs can scope this out in the near future. @gismar has said that he is personally interested in this feature and will look to allocate some time towards a feasibility study, but he also agrees that his time must be prioritized towards DIGG right now.
If none of the above sounds “soon” enough for you, please look into scoping out the requirements as a community yourself or with another developer you know that might like to contribute to furthering Badger. If someone were to scope this out and recreate the BIP with the relevant details under “Implementation”, and if it were to reach threshold, we can vote on it to snapshot and formally add it to the backlog. Until then, please be patient.
Reiterating my point above^.
For the sake of focusing your discussions on this topic, I will leave this thread open and pending.
If you’re going to say that about this BIP, then you should also do the same with BIP 19.
Thanks for your feedback. People are already investing significant time and effort in the buildout of BIP 19 from a business and technical standpoint and how it’s implemented.
Fantastic, I look forward to seeing the progress and models then. =) Until then, you should probably not push BIP 19 to a snapshot.
hello guys I voted yes. I believe that if it is 100% of the rewards for re-investment it would be a good one as well, because it is better to have automatic staking already, we do not need to pay fees to reinvest the badger and whoever needs to take to sell tb and only take as much as they want. but it would be very good 100% automatic reinvested q would save for us non whales the gas rates could have an option 50% and 100% and the user decides.
I agree. a bbadger supersett that took the badger emissions and reinvested them and just shared it’s the geyser multiplier with everyone in the pool would be an awesome solution to this problem.
With all due respect, I don’t like the “Discord voices” being used as a prioritizing element.
It is all a matter of perception.
The claiming / restaking fees are, as it seems, a pretty serious issue for many.
I think this BIP should be amended to also include this option for Digg rewards too.
Thanks all for the valuable feedback on the proposal. I think it is clear that this a user pain and the idea is accepted to proceed to work out the technical details.
Since I don’t have the technical skills, it comes down to what @DeFiFrog mentions: