V1 Release Backlog & Timeline

Hi guys! As mentioned on Town Hall today, the breakdown of our current v1 backlog looks like this:

  • 40 status-react issues, 1 status-go issue
  • 11 keycard-assigned issues, 30 core-assigned issues
  • 14 currently in progress by the core team & bounty contributors
  • 6 remaining in the core p0 (must-have) column
  • additionally - there are ~30 issues in the private Trail of Bits repo, but only a fraction need to be fixed for v1. More to be reported for status-react over the next weeks.

I estimated on Town Hall that we have minimum 4 weeks of effort left til a v1 build is shippable.

One big open issue at this moment is proof of ownership. I’m working with the product team to make the right decision on how to handle this, with the goal being to enable fast & easy transfer of SNT to new users by our community team during launch.

3 Likes

Okay, here’s the latest…

Unfortunately, we’re down a team member. Dmitry N., who was the primary owner for keycard issues in status-react, will no longer be working with us.

We’re looking to backfill his position, but in the meantime, we need to plan on moving ahead with the team we have.

So we held a call to get alignment on the remaining v1 must-haves. Trail of Bits provided us with their final report this week, which means we now have a complete picture of work remaining. :slight_smile:

Luckily, getting alignment on the remaining scope was easy. This spreadsheet (internal only - sensitive) now offers the best view of our v1 backlog.

  • 28 items are must-haves (:tada:)
  • 10 keycard; 7 security issues; 11 core (ENS, onboarding, misc. bugs, etc.)
  • 9 in progress
  • 2 owned by bounty contributors; 7 by core contributors
  • 10 addtl nice-to-haves; 5 being worked on by contributors

We’ve been dutifully filling out planning poker spreadsheets over the past few weeks, though I’d say the data has been too inconsistent to come up with an accurate translation for points : time. I’m still going to make sure we have estimates for all the feature work in this list + will offer a fuzzy timeline once I do.

At this moment, I don’t think it would be smart for us to aim for a pre-Christmas release date—though it might in fact be feasible, it wouldn’t be comfortable, and I want to protect all of our sanity.

Edit: I want to add - if we target mid-December to have this scope completed, we could spend the second half of December dogfooding. I really like the idea of having buffer for testing, and it’s only a couple of weeks difference.

Please let me know if there are any questions!

4 Likes

Just wanted to say shout out to you all involved in v1 - it’s not been an easy road to travel and you’ve all managed to keep things moving forward so consistently. I can only imagine how much hard work and focus that takes, so props.

These updates are super helpful so thank you @rachel and everyone else in sharing these so diligently. Glad you all are taking care of yourselves and setting a v1 deadline that keeps everyone sane.

Thanks for the detailed update Rachel. Aiming for a post-Christmas release date seems more than reasonable to me given the circumstances.

On the People Ops side of things, we’re certainly prioritizing backfilling Dmitry’s position to help alleviate some of the pressure :slight_smile:

3 Likes

Thanks for the update and transparency @rachel! Sucks to hear about Dmitry, great work on soldiering on and Core doing all the final crucial bug and security fixes before v1!

Regarding scope, I’m not convinced we couldn’t be cutting more of it and be more radical. From my point of view, anything that can be done in a v.1.0.1 release should be. The only exceptions are:

  1. Critical security fixes
  2. Showstopping bugs

When I look at the spreadsheet of must-haves that are not in progress yet, I see a lot of bugs that don’t appear to be showstoppers to me. I took the liberty to look over the scope based on information given in GHIs (so I might very well be missing reasons why bug x is 100% a showstopper) and created a copy of the spreadsheet above (https://docs.google.com/spreadsheets/d/1nxNhx4Hf4l7kgGL-IlQvYTqEhOF_-mGQ6kOtXUT97CI/edit#gid=1167593595) where I marked things that I think can be in a v1.0.1 release.

Considering the state of Keycard UI-wise, I’d consider that integration more of in a alpha/beta state, given the many (especially very recent) reported issues. The critical thing is the key structure.

With this, somewhat more radical scope cutting, around 80% of those issues would be deferred to a follow up release.

It’s up to to you guys in Core to figure out what you are comfortable with (and I know you’ve had several conversations about this), but perhaps that input is useful and we can be more radical about cutting scope to get a release out earlier rather than later :slight_smile:

Edit: Another interesting thing to note about these issues is how few of them are user-reported. This is partly due to not many people using nightly, us not releasing beta release in a while, and not having more users. Organic user bug reports are more potent and more likely to isolate the top 5 critical bug fixes needed for v1.0.1 based on actual user input (80/20). Globally, the biggest bug right now is that Status isn’t publicly released yet.

Thanks all :slight_smile:

Globally, the biggest bug right now is that Status isn’t publicly released yet.

Agreed fully, @oskarth. Also agreed on the pushback re: Keycard issues.

If you look at the Core board, we now have 8 critical issues in progress, and 5 yet to be started (P0). I’ve moved one of the wallet bugs (broken Tx history) + the keycard UI fixes and reset feature to p1.

Accounting for audit issues, that means 20 items remain open and in scope. I’m not convinced this should change our timeline—as for marketing purposes we wouldn’t want to go live later than mid-December—but let me hear from the team and get back with an update.

Several of the other issues in progress are being worked on by contributors, so if they get finished, we’ll include them.

1 Like

I’m back with some info on timelines:

I think we can have these 20 issues completed by ~7-10 December.

The biggest outstanding item is SNT distribution (/send and /request commands), which Eric is owning. The audit work is also somewhat variable in scope—Oskar, Andrea and Adam are working on a strategy for mitigating certain protocol level threats, which are not completely solvable. ~4 weeks feels like a reasonable amount of time to satisfy the reported issues, and the other items can be owned by Andrey, Vitaliy and Roman in parallel.

We could then feasibly launch by mid-December.

It’s a question of whether we want to. Do we push for a mid-December timeline and go live right before the holidays? Or, spend the second half of December dog fooding, triple checking our comms & enjoying time at home?

We need to get the app out there, I recognize that, but we’re talking about a difference of two weeks, during which many people will be taking time away from their devices to be with family or travel.

Any thoughts? Special ping for @jonathan, and the team who will be called on to investigate bugs when we’re live @andrey @yenda @roman @vitaliy @adam @cammellos @pedro :slight_smile:

It’s a question of whether we want to. Do we push for a mid-December timeline and go live right before the holidays? Or, spend the second half of December dog fooding, triple checking our comms & enjoying time at home?

I would not go live before holiday, lots of people will be off during that period, rather I would dog food until we are back at least (we could ideally release a rc v1 to the public)

1 Like

The pro of waiting until January (allowing the team to enjoy a well-earned holiday break) for launch outweigh the cons (shipping a few weeks later) IMO.

1 Like

Echoing @ceri’s comment. @Core you are all awesome for soldering through this uncharted territory!

Agree on the further scope cutting. And support a post-Christmas launch if that secures the team’s sanity. I’ve very much been a proponent of releasing early to learn. However, I suspect launching Mid-December will result in a tsunami of bug reports that will than need to be dealt with during the holidays.

An alternative suggestion would be a Go/No go date on EOD Dec 3rd. Reserving the rest of this week till Dec 10 for release cut and comms prepping.

This would need to be combined with requirements for Go/No go decision making, e.g. all issues currently in the spreadsheet are merged. If these requirements are not met by Dec 3rd. The release would be post-christmas.

1 Like

There are pros and cons to both scenarios (before / after holiday) but I would prefer to go live after the holiday.

December is already a pretty quiet time for press and media due to holidays, people spending time with family, and the reporters themselves not covering as much. As PR is a fairly significant part of the launch strategy, we can have greater impact in early Jan.

Selfishly, this provides a bit more time to ensure all comms are prepped, triple checked, and ready to go without any scramble. This also allows us to coordinate the launch with some other campaigns we have going on which will create a very active and media rich Q1 2020.

We have been working towards this moment for a long time so there will certainly be some negative community sentiment – but we can plan for that and handle accordingly.

2 Likes

I also agree with the current v1 priorization for keycard items. I added notes in Rachel/Oskar spreadsheet for each issue to detail them and explain how critical they are.

With this scope, Status v1 will have a alpha/beta integration of Keycard. Meaning all main features are here, but usabililty and ux will need to be enhanced. Andrei & I went through a review of usability in the past weeks, and that’s why lots of new issues have been posted in github. These are thus post v1.0.0 developments.

:warning: it’s super critical that Keycard is actually used so that we report/work on the right usability points.

If you don’t have a keycard, or miss something to use it with the nightlies, please ping me !

2 Likes

So we have consensus - early January 2020 is when Status v1 will go live. :raised_hands:

We’re now closing out remaining bugs, finishing the new /send and /request command GUI, and mitigating certain reports from the Trail of Bits audit.

Additionally, we’re doing a bit of preparation for app upgradeability and backwards compatibility once v1 is live.

You can view a pretty comprehensive demo of v1 and all its bells and whistles in this awesome recording by Andrey.

2 Likes

That music choice in the video, that’s a pretty obscure jazz record :slight_smile: ( Hiroshi Suzuki - Cat (1975) for those who’d like to have a listen)

6 Likes

It’s been a minute since I updated this thread! What a blur.

Last week was the target deadline to have our release cut ready. We are a week overdue, but we’re close and still targeting a Jan 2nd or 3rd app store submission.

Chu, Sergey and I have been dogfooding steadily for the past several weeks and reported a handful of new issues. The best overview of our remaining issues is the v1 release label in Github. With Christmas and New Years ahead, I’d like to cull this list further.

One concerning issue became apparent as we started using Keycard with Samsung Galaxy devices. It seems that cards are being wiped when we try to recover them, on Galaxy devices in particular. We’re investigating.

Today we fixed a critical issue with DApps not appearing on https://dap.ps. We’re very close to being prepared for app upgradeability, fixing a lack of transaction history when there are too many Txs, replacing Infura with Cloudflare, and shipping the new chat command flow as well.

Huge kudos to the team on working so diligently during these past few weeks. We’ll be excited to have this scope wrapped and v1 out the door. :muscle:t3:

1 Like

It is now January 13 and there are still a lot of issues open here https://github.com/status-im/status-react/issues?q=is%3Aissue+is%3Aopen+label%3A"v1+release" - are we going to release v1 in January or what’s going on?

Yes, good reminder that a public update is overdue.

We just merged chat commands, and from my POV, we’re ready to submit to the stores.

We have important fixes coming to transaction history, which are close. But I’d like to go ahead and submit a build tomorrow so we can get a response from Apple & Google ASAP. We’ll also distribute this build internally and to our ambassadors for dogfooding.

Any show stopping bugs will be addressed before we release publicly. I’m in close contact with Jonny & team about our launch plan, and going over it today with the product team so we can discuss user support.

FWIW I attribute our tardiness to a) run-of-the-mill underestimation, combined with b) the holiday vortex slowing us down and exacerbating the discrepancy between our estimates and reality.

Although we’ve been estimating story points in a spreadsheet, I’m looking into ways that we can have more accurate, data-driven timlines—likely using a tool like Fogbugz, which Andre is a big fan of.

1 Like

Follow up after our launch call yesterday:

  • Though we are concerned about the likelihood of messaging issues if we scale to, say, 5,000k+ users…
  • And the merit exact dependability of Waku is unproven, with more information to come within 2 weeks…
  • Carl & Jarrad are onboard with a full launch pre-Waku.
  • Jonny & team are preparing responses for known issues that may crop up.
  • And overall, we feel confident that we’re delivering a drastically improved version of Status from the beta that our community is familiar with.

The marketing plan includes press in crypto-centric publications, our traditional social channels, support from the ambassadors and a few AMAs and interviews with Carl & Jarrad.

To support the launch, we’ve prepared a user guide, added a glossary to the profile screen, and we are updating the FAQ.

We have data on unique peer IDs (roughly equivalent to users or at least their devices) ready to monitor.

Chu, Sergey, Andre and I are joining forces to test open PRs today.

When we go live, we’ll offer user support in #status in a fairly ad hoc fashion. I’m in Asia, the bulk of the team is in Europe, André/Corey/Jonny are on the east coast, and I believe Andy is even on the west coast—so if we all agree to check #status a few times a day, we’ll be well covered. :slight_smile:

Questions, concerns, etc. welcome.

5 Likes

Quick, but happy, update:

  • The develop build we submitted to Apple last week was quickly green lighted for App Store release.
  • We are planning to merge some important, release-blocking fixes to wallet Tx history this week.
  • In the meantime, we will be distributing a release candidate to Status core contributors and ambassadors for systematic dogfooding of the application.

CCs & ambassadors: stay tuned for directions on how to dog food coming today.

We also revised our launch marketing strategy. We feel great about the progress being made on the Waku project—which will help Status scale to more users by a) reducing bandwidth consumption for users who opt in, and b) making it possible to support a higher number of users on chat—but as the project’s completion is still weeks away, we need to be mindful about not overloading the protocol on launch.

Thus, we’ll communicate v1’s availability only via our traditional channels: social media, ambassadors, our blog, etc. We will not aim for any PR or media coverage.

It’s critically important to us that we deliver on our promise to get v1 into our community’s hands, and we’re thrilled to be nearing this milestone very soon.

3 Likes

Hi all!

Testing is going well. We created a new release candidate today (RC3) with bug fixes from last week.

No major new issues have been identified, and we’re busy making last minute adjustments and troubleshooting a slow connection issue when the device is reawakened from sleep.

The issue count for v1 release is currently at 8 little issues.

We’re feeling good about the state of things. More updates to come soon.