V1 Release Backlog & Timeline

Status Mobile
1

Hi all! I wanted to share a quick state of the state re: v1.

First, the audit kicked off this week. We’ve included one final technical task to the scope of work for audit: Store EIP1581 extended key.

The remaining work required for the release is labeled v1 release on Github in both status-go and status-react. Here’s a rough breakdown:

  • 59 open issues
  • ~70% are bugs :flushed:
  • The feature work is estimated to be > 100 story points
  • Bugs are not estimated

The features selected are:

I’ve loosely split the bugs into blocking and non-blocking in Wrike (based on my projection of Reach x Impact) and believe we could narrow the list by 8-10 issues.

I’m organizing the work into the Core project board so that Status org members can have a view into work selected, by whom, and what’s next in the pipeline.

As we progress with planning poker every 2 weeks, we should be able to crisp up the estimates above and convert them into soft timelines, so stay tuned.

9 Likes
2

For posterity, these slides are where I initially called out the remaining feature work. Because some people have asked about the below, it also lists several nice-to-haves:

  • Proof of ownership for sending funds to contacts via wallet / re-enabling chat commands
  • Add a ‘watch only’ account
  • Pin code login

Much rather get v1 out the door than stuff more features in, myself. But we’ll see how long it takes us to crank through bugs & whether we end up with spare capacity near the finish line.

2 Likes
3

I am definitely on the side of spending resources on fixing bugs than adding features.

5 Likes
4

It was a fabulous week in Statusland.

Progress

We saw the v1 release backlog jump from 60 down to ~45 issues. Way to go, team. In fact, we’ve closed out 50% of the issues mentioned in my original post:

And then some—UI onboarding fixes are merged, as is bonus feature biometric login. There’s also been great progress toward ENS verification, bugs fixed, new e2e tests written, and more. :tada:

For more details on this week’s progress, see the retro notes here.

Decisions

  • I added proof of account ownership—and subsequently, revival of chat commands + send to contacts from wallet—to the v1 scope. Why? We want to facilitate grassroots SNT onboarding at launch. We’ll welcome new people into a dedicated intro chat, and share the SNT wealth with them so they can register for usernames, use stickers, and vote for features and improvements using SNT.
  • We may disable push notifications for v1. The proposal to do so is here. Before we pull the trigger on this, I’d like to see a bit more rigor behind the alternative proposal. On the bright side, this reduces our overall surface area for bugs and will allow us to invest the time we’d spend fixing current PN bugs, back into chat commands.

Any thoughts on that, please speak up here or ping me.

4 Likes
5

Update! I’m back in action after being under the weather last week.

Great progress from the team once again. Although our v1 release issue count tends to follow the ‘one step forward two steps back’ pattern, we’ve knocked out more key work.

Overall, we have 45 open v1 issues in status-react, 2 in status-go and 2 in status-protocol-go.

Of the issues in status-react, 60% are bugs. 24% belong to Keycard and are logged on that project board. The remaining are logged for Core.

3 Likes
6

Decision on push notifications - we will disable them for v1.

Android
@yenda’s experiment with a POC for notifications running as a service on Android was successful. If we build on this POC we’d be able to reliably notify users of their DMs, PNs, wallet activity & more, for a reasonable amount of battery consumption (2% in 3 hrs). As I understand, we’d want to run notifications as a status-go service and it’s not a small undertaking.

iOS
For iOS, we have less hope of a decent decentralized solution. @andre has researched the feasibility of using background refresh to deliver notifications. Because iOS uses a sliding algorithm to determine when your app gets screen time - the feasibility is basically zero.

We are at square one here. The current implementation - which uses a centralized service, requires users to be running the app in the background, requires users to be contacts to deliver PNs to each other, and only supports DMs (no other type of notification) - is currently the limit of what’s possible without further degrading user privacy.

For v1

I would like to fully disable PNs.

We speak about a) not shipping janky features, and b) decentralizing as much as possible. PNs currently violate both of those principles.

I do worry about shipping a messenger without a feature that is so essential for user engagement. But shipping PNs that only half work is no better than shipping no PNs at all.

Moreover, we have a handful of bugs relating to PNs that we can save time to v1 by cutting.

And, it’s a more powerful statement to remain true to our principles. That we don’t have PNs can help to convey what Status stands for when we launch.

Beyond v1

I’d like to propose that we discuss PNs as part of the “make chat enjoyable to use” objective. They can be ranked alongside other basic chat features such as image sending, mentions, etc.

I would also like to speak with iOS users to understand whether the tradeoff of relying on a service like Firebase is worth it to have imperfect PN support. And, I’d like to better understand the technical implications of maintaining Firebase to support PNs for this userbase only.

Thanks @yenda and @andre for your work to validate Eric’s proposal. I’m glad to know we can have excellent notifications running true to our values on one OS, at least.

3 Likes
7

As a non-technical contributor, it’s pretty cool to be able to read (and understand) the debate and rationale for some of these product decisions - thanks to everyone on the thread for the transparency!

Will users receive an in-app message letting them know that PN’s are disabled (so they know not to expect them), or will that happen via launch comms?

1 Like
8

As I understand, we’d want to run notifications as a status-go service and it’s not a small undertaking.

Notifications are already working on Android. Running status-go IN a service is only an improvement in terms of convenience, it will allow the user to restart the service by tapping on a notification. Right now on Android the only difference is that the user needs to start the app UI once.

To summarize what we already have on Android (but I need people to test on different device):

  • status running as a service after being started
  • notifications for messages (but can be extended for anything while the service is running)

For the notifications to feel reliable what we also need:

  • BroadcastReceiver to display notification on startup inviting the user to login to receive notifications from Status
  • optionally ScheduledTask to check if the service is running (though optional because the service was never killed in 2 days when app is locked in recent apps).

Basically the user just has to be aware that Status needs to be running for notifications to work, and for that it displays a sticky notification that says it is running, and after reboot of the phone, a notification that says it needs to be started if the user wants notifications from Status.

I should have finish all of the above (except ScheduledTask) by Monday. I need some help to test the behavior (service being killed, battery, reliability) on multiple Android device so if you are willing to participate to testing please send me a message in Status or on Discuss. I have notifications on Status now so it’s more reliable for me than discuss :stuck_out_tongue:

Additionally I think that if there is no working solution for iOS, we can send iOS notifications through desktop or waku nodes, so that would incentivize iOS users to run these since it would be the only way to get notifications

9

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
10

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
11

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.

12

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
13

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.

14

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
15

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:

16

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
17

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
18

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
19

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
20

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