Having an SDK or a fully permissionless, audited smart contract with configurable parameters for rewards distribution could help avoid delays when creating experiences outside The Sandbox client.
I believe this would add significant value and simplify building within the ecosystem.
It’s crucial for The Sandbox team to stay attentive and clearly define the scope of the proposal in collaboration with the community to ensure that funds are used effectively and that the development remains truly feasible.
It was lenghty, which isn’t particularly a bad thing.
Also got follow up notes to highlight some parts that needed more details, that was attentive and good feedback.
It made me think that SIP’s should be somehow divided into:
1 - SIP’s that are dependant on TSB road map and TSB product development team, like this one.
2 - SIP’s that are independent from TSB road map and staff, like Magic Palette for example.
The SIP’s that would fall into the first category, it should have a simpler approach, since most of the time, the SIP authors aren’t asking for funds, neither have the needed to directly work on it, since it falls directly on TSB product development team.
The shared road map as it was proposed in here, having some blank spaces to be filled by requests from the DAO, like this one and yours on the invetory filer, would allow to the community have reserved space into the road map, to prioritize whch features are the most urgent for the product team to work on, while not deviating them from internal road maps.
That would also give the community a sense of responsability on what’s important/urgent, since time is finite so are human resources to develop the things we ask.
It is certainly important to distinguish between these two categories. You’re right. Just to keep the Forum UI/UX as simple as possible, we may be reluctant to split categories much further than they are already.
But it will be an important distinction to make for any SIP authors. You did a great job clarifying this here, @PickaxeMaster!
We really need to get that TSB Product Development Roadmap, @Cyril!
Note to the community: We have been pushing for this through weekly requests from the TSB team and have not yet received a 2025 product dev roadmap. It is very clearly a critical resource to keep us aligned. THANK YOU for your patience.
I’ll make sure to attend it and it’s good to see those initiatives take place.
As for making more tabs, I understand you, sometimes less is better.
What I wanted to point out, is that more and more SIP’s are going to request things that have direct impact on the Development Team.
I’m aware they have so much people and time to work on features, and they have to prioritize on whats developed first. I trully respect the Development Team, as they are probably getting resquests from left to right, and it’s a though choice to decide the priority of things.
Probably a lot of SIP’s here are already in the Product Team’s road map, knowing what that is, would allow to save time on making outdated SIP’s and align expectations with the time it takes to develop and implement features.
Myself and surely others are more willing to accept a “We’re late, I’m sorry” than not knowing anything at all.
More than anything, all I want is for the UGC and the Product Team to be more coordinated, so we both can make the best for the Sandbox and the Community as a whole.
Roadmap is a very strategic component and I can understand that the team is taking long to get that one out as investors (incl. myself) are very keen to dig in those using them to time their perspective. What would be seen as super positive from creators, builders might not be seen the same way by investors.
Coming back on the topic of development team. Why can’t we decide to outsource via RfP (request for proposal) the biggest part of development of features if the internal team has no resource. Do wou always needs a strong connection with internal?
What would that process look like?
and, I’m looking forward to your new SIP idea!
you’ve been crushing it with activity in here lately