We want to try to Launch on the 21st of December… Yalda Night, Winter Solstice, and Lauren’s Birthday!
If we miss it… then we push to Launch to Christmas!
So the DApp has to be ready for this!
The Features that are critical for launch (IMO):
A PERFECT DONATION FLOW with GIV
The Giving Block Integration
The Header
GIVbacks complete functionality (Token Registry, backend tracking, etc)
GIVbacks Explainers in the UI
Emails Explaining GIVbacks
TESTING TESTING TESTING
The Features that worry will have a bad user Experience if we include them for launch:
Transak
Donation via Address (It’s not just the QR code)
So what to do?
The Typescript version is not going to be ready at launch. This is for sure… that gives us 2 choices
Do we use the deployment we have, the devil we know,
or
Do we try to make a hybrid with the Typescript deployment for the critical pieces.
or
Do we delay the Launch for the DApp to be ready
Moenick says this is my call… but i don’t think I have enough info to make this call… what I do know is I am not interested in delaying the launch if the GIVeconomy is ready… and look at how close it is: https://liquidity-mining-dapp.vercel.app/
Let’s get this party started! The DApp can’t be a blocker… I am leaning toward using the old DApp as it is the Devil we know and it has been thoroughly tested, then we can release the new DApp after we launch as a big reveal… Always nice to have good Comms come later.
Launch now! Add more features later. I think turning the pressure off to complete all these tasks in just a few short weeks will allow us to thoroughly build/test each component/feature before it is added to the DApp. Decreasing the scope now will potentially decrease the scope of the fires we need to put out (technical emergencies) that we’ll need to deal with during the first initial weeks post launch.
I say let’s have the devil we know ready to be our backup but let’s focus on bringing the release with typescript and all the greatness we’ve been working on. With the help of Vitor and Ramin we can pull it off front end side, Mohammad and Carlos having our back, from 7th to 14th coordinating with design and allow testing from 15th until 19th, focusing essentially on:
Authentication Flow (Frontend Only Typescript dApp)
Donation Flow (Frontend Only Typescript dApp + Design)
Create a project Flow (Frontend Only Typescript dApp + Design)
Giving Blocks Integration (Both Frontend dApps)
GIVbacks Tracking (Backend)
If we don’t make it and decide to go with the devil we know we’d just have to make sure that the giving block integration is right (I’ve heard backend work is done 90%, it’s just a matter of integrating to the front end which is easy). For the features that worry you I would say Transak is ok, it’s just not widely tested but should work fine, donation via QR/address can totally wait.
My main point is that the current dApp is fine and doesn’t need much work on so it’s ok to try our best to bring the new king at play, if we don’t we launch anyway and throw the new version later, but being honest I dream of a launch with the new kickass design so everyone that goes there has an intense urge to give and give back I also agree that if the GIVeconomy is ready we can’t delay it anymore.
Also @dev and @design teams, it may mean working A LOT harder for a couple of weeks, It’s totally fine if you don’t feel like it, don’t feel the pressure just because I’m saying that we could pull it off, I’m feeling optimistic!
Also also, this doesn’t have all the latest but if you are curious to see this is how the new version is looking https://typescript.giveth.io/
I believe setting a date is important to do the final push forward to really leave everything stable and get work done.
1 Week finishing remaining tasks + 1 Week of pure testing.
So 2 weeks from now for the 21st is a great date in my opinion.
As for decreasing the scope, I agree with Mitch to focus on making it stable now and then add features later.
Regarding the frontend, Mateo and Ramin can make that call. But I do believe using the devil we know is the sane option for the launch as we already have control over the current issues and posible bugs that may arise, rewrites might bring another set of emergencies that we might not expect.
For backend, my current focus is the giving blocks which I left a PR for Mohammad to review and we will be testing it this week to merge it soon. There are somethings left for discussion tho.
But most of the work left like Mateo said is frontend + design.
Summarizing: Great date to release, I think we should use the current frontend for release, add features later to decrease the amount of technical emergencies for launch.
We are airdropping GIV to thousands of people… I would just remove this from scope all together since it’s not relevant to that, so we don’t have to test it… it’s not critical so considering the deadline it’s an easy thing to remove from our todo list IMO
But then… 1 week later BOOM release it and make waves with it!
Reducing scope is imperative if we want to release the GIVeconomy in 2021.
A big reality to realize and accept is that we have no dedicated testers and also that much of team is not very familiar with the details and functionality of the GIVeconomy.
I think we should:
finish the Giving Block integration
finish outstanding components of the GIVeconomy (univ3 pool, frontend fixes)
reduce GIVeconomy scope by removing GIVstream history table
create the new header for the DApp to it’s consistent with GIVeconomy
create staging deployment of DApp + GIVeconomy together (with old frontend)
finish comms around GIVeconomy have all documentation ready to blast off
Then get everyone testing. Get devs testing, designers testing. When we launch we will need our team to support people coming in, and in order for that to happen we need people understanding how the GIVeconomy works.
I think we should try to finish everything we can this week, maybe mid next week if not. Then test, then fix bugs, then test, the deploy.
I think it can be a good thing to update the design after launch… It’s like delivering more and more and more rather than just blasting everything at once (at Christmas) which could just be like… tmi and no one will be able to notice all the details. For comms, I like to have little bits of things to say over time… so we stay relevant and interesting.
Launching the GIVeconomy at christmas is nice because it can be framed like a gift… but I realistically think people won’t be spending TOO much time w the DApp right away because they will be with family etc. Following up early in the new year with a new design (new year, new Giveth) would be nice as well.
Anyway, love you all. Tl;Dr - I think cutting scope, testing all together as a team and then being really unified at the launch with everyone being an expert on what we’ve got is the best way forward.
I personally agree with cutting the scope and launching sooner, it would be better to not become bombarded by new users at the beginning , saying that Xmas people are on holidays and don’t spend much time on Dapp right away, so it allows us to launch with enough time to support and fix possible post launch bugs with peace of mind! after holiday season finishes, we can spread out blurbs and go wild on social media on our launching and features and … expose our products to public
I’m good with keeping the launch scope clean and tight… AND…
Having a clear plan for releasing the additional features then delivering them is important…I know “no dates”, and … x weeks post launch for target releases would be nice to keep some goals around added functionality.
I also agree that if the GIVeconomy is ready we can’t delay it anymore.
