Re: [wake-lock] Break specification into levels (#253)

Taking this at face value, the proposals to do levels sounds reasonable. And would allow the spec to progress along the Rec track - and hopefully I can convince more of my colleagues at Mozilla that wake locks is something we should implement... or they will convince me otherwise! 😂😭

But, I have two things I'd really like us to consider before moving forward:
 
 1. As a Working Group, we should try to convince other browser vendors that "system" and other locks add value to the platform. Or, alternatively, we should look at "what are we really trying to achieve" with those lock types: The "Starbucks" use case for wake lock was really compelling, because it gave us a real user story that everyone could relate to (the social anxiety was easily transferable to anyone who has ever boarded a plane, or tried to get into an EventBrite event, with a digital barcode). 

For new wake locks, I think we need to create a simple document similar to https://www.w3.org/TR/wake-lock-use-cases/ - that *shows* real use cases/apps, but it doesn't try to force a solution... and find our "Starbucks use case" for the other locks. What I'd like us to get to is, "users are in situations where they are trying to do X, but Y is happening because the platform lacks Z... and that's sad". If we can see what the "Y" is, we can then decide if a particular wake lock is a solution.

Right now, it feels like we are trying to add the other locks because Android has them - but not because there are strong compelling reasons to do so (at least, I don't have anything I can sell internally where people go - "oh, yeah! that happens all the time and it's terrible. We NEED that in the platform!"). Or, put differently, we have a bunch of solutions ("cpu", "system", "wifi", whatever) looking for a problem.  

 2. Level'ed specs can be hard to maintain because "levels" usually contain all the stuff from previous levels. This makes them a bit of a nightmare to maintain, because any changes we make to L1, we need to propagate to other levels too (this becomes a mess as each level start to diverge, and without really careful planning on how the document is structured). So, it might instead be good to: 

 * incubate new lock types in Pull Requests - PR Preview lets interested parties see what's being added, and it takes away some of the maintenance burden (but still a bit painful).  
 * Spin up a separate doc for the new wake locks. Incubate/socialize the new wake locks and see if we can get other folks interested. The just publish the new wake lock independently of the original spec.  

In all case, the W3C Process will prevent us from advancing these docs along the Rec Track due to it being of single implementer interest. Like all of us here, I'd like for us to work to overcome that. 


-- 
GitHub Notification of comment by marcoscaceres
Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/253#issuecomment-591219455 using your GitHub account

Received on Wednesday, 26 February 2020 03:25:46 UTC