Reorganize the repo structure (WICG#27)

The repo was getting unruly, with a mix of explainers and brainstorming
documents. This patch makes the following mechanical changes:
 - Create explainers/ directory for explainers
 - Create misc/ directory for brainstorming and misc docs
 - Rename files to consistently use lower-case-with-dashes

Author: shaseley

README.md

@@ -30,7 +30,7 @@ main thread work. Since long tasks and responsiveness are at odds, breaking up
 long tasks can help keep an app responisive when also *yielding to the browser's
 event loop*.
 
-[Userspace schedulers](UserspaceSchedulers.md) have evolved to manage these
+[Userspace schedulers](./misc/userspace-schedulers.md) have evolved to manage these
 chunks of work—prioritizing and executing work async at an appropriate
 time relative to current situation of user and browser.
 
@@ -54,7 +54,7 @@ there are several problems they still face:
     script. This disincentivizes yielding for script that requires low task
     latency.
 
-    We propose adding [scheduler.yield()](YieldAndContinuation.md) as a
+    We propose adding [scheduler.yield()](./explainers/yield-and-continuation.md) as a
     solution.
 
  3. **Coordination between (cooperating) actors**: Most userspace schedulers
@@ -71,7 +71,7 @@ there are several problems they still face:
     scheduling decisions to help improve user experience.
 
     We propose adding a [prioritized postTask scheduling
-    API](PrioritizedPostTask.md) to address this problem.
+    API](./explainers/prioritized-post-task.md) to address this problem.
 
  4. **A disparate set of scheduling APIs**: Despite the need to schedule chunks
     of script, the Platform lacks a unified API to do so. Developers can choose
@@ -82,7 +82,7 @@ there are several problems they still face:
     write scheduling code, and requires expert knowledge of the Browser's event
     loop to do so. Creating a unified native scheduling API can alleviate this.
 
-    This is also addressed by the [postTask API](PrioritizedPostTask.md).
+    This is also addressed by the [postTask API](./explainers/prioritized-post-task.md).
 
 ## Additional Scheduling Problems
 
@@ -91,12 +91,12 @@ space.  Additionally, there are developer needs for things like detecting when
 a frame is pending, throttling the frame rate, and avoiding layout thrashing.
 
 Some of the other APIs we're considering in this space are noted
-[here](LowLevelAPIs.md).
+[here](./misc/low-level-apis.md).
 
 ## Explainer Links
 
- * [scheduler.yield()](YieldAndContinuation.md)
- * [scheduler.postTask()](PrioritizedPostTask.md)
+ * [scheduler.yield()](./explainers/yield-and-continuation.md)
+ * [scheduler.postTask()](./explainers/prioritized-post-task.md)
  * [isInputPending()](https://github.com/WICG/is-input-pending)
 
 ## Further Reading / Viewing

PostTaskPropagation.md explainers/post-task-propagation.md

@@ -1,6 +1,6 @@
 # Main Thread Scheduling: Prioritized postTask API
 
-For an overview of the larger problem space, see [Main Thread Scheduling API](README.md).
+For an overview of the larger problem space, see [Main Thread Scheduling API](../README.md).
 
 ## TL;DR
 
@@ -11,7 +11,7 @@ experience), but the Platform lacks a unified API to schedule prioritized work.
 ## The Problem
 
 To keep apps responsive, developers can (and should) break up long tasks into
-smaller chunks.  [Userspace schedulers](UserspaceSchedulers.md) often manage
+smaller chunks.  [Userspace schedulers](../misc/userspace-schedulers.md) often manage
 these chunks of work (tasks)—prioritizing and executing work
 asynchronously at an appropriate time relative to the current situation of the
 user and browser.
@@ -41,7 +41,7 @@ tasks of a given task source.
 
 The current state of prioritization in the browser looks something like this:
 
-![Current Web Priorities](images/web_priorities_current.png)
+![Current Web Priorities](../images/web-priorities-current.png)
 
 The first two—*microtask* and *don't yield*—are generally
 antithetical to scheduling and the goal of improving responsiveness. They are
@@ -101,7 +101,7 @@ covered by this minimal set of priorities. We also understand that apps may have
 finer-grained app-specific priorities, and are considering additional APIs to
 support these (see FAQ below).
 
-![New Web Scheduling Priorities](images/web_priorities_proposed.png)
+![New Web Scheduling Priorities](../images/web-priorities-proposed.png)
 
 1. **user-blocking**: User-blocking tasks are tasks that block a user from
    interacting with and using the app. This could be (chunked) work that is
@@ -384,7 +384,7 @@ scheduler.postTask(() => { console.log('B'); });
 The API shape described above is the current MVP. The following are
 extensions of the base API that are in various degrees of exploration:
 
- 1. [**Propagating and Inheriting Priority**](PostTaskPropagation.md): A
+ 1. [**Propagating and Inheriting Priority**](post-task-propagation.md): A
     frequent request we see from developers is the desire to inherit or
     propagate the currently running task's priority.
 
@@ -452,15 +452,15 @@ lightweight solution and will publish an explainer soon.
 Priority inversions occur whenever higher priority work depends on lower
 priority work, so simply by introducing priorities introduces this risk. There
 is only so much the API can do to prevent these situations, although [inheriting
-priority](PostTaskPropagation.md) can help to some degree.
+priority](post-task-propagation.md) can help to some degree.
 
 
 This is something that developers should be aware of whenever using
 priorities, and should guard against in situations where a resource is shared
 and can be accessed by multiple, different priority tasks.
 
 Some of the situations where this can occur are explored
-[here](PriorityInversion.md), as well as potential solutions. It is not clear
+[here](../misc/priority-inversion.md), as well as potential solutions. It is not clear
 at this point that a native solution beyond `TaskController` is needed, and we
 await further developer feedback from Origin Trial.
 
@@ -503,11 +503,11 @@ concurrent mode).
 The proposal orignally included the ability to pass arguments to the callback,
 like in `setTimeout`, but was removed because modern JS supports arrow functions,
 which obviates the need to pass them through `postTask`
-(see [this issue](https://github.com/WICG/main-thread-scheduling/issues/18)).
+(see [this issue](https://github.com/WICG/scheduling-apis/issues/18)).
 
 ## Security Considerations
 
-**Note**: This section summarizes [this much longer exploration](PostTaskSecurity.md).
+**Note**: This section summarizes [this much longer exploration](../misc/post-task-security.md).
 
 The main security concern is whether or not the API adds new surfaces to
 perform side-channel attacks, specifically for same-process cross-origin

PrioritizedPostTask.md explainers/prioritized-post-task.md

@@ -1,6 +1,6 @@
 # Main Thread Scheduling: Yield and Continuation
 
-For an overview of the larger problem space, see [Main Thread Scheduling API](README.md).
+For an overview of the larger problem space, see [Main Thread Scheduling API](../README.md).
 
 ## The Problem
 
@@ -31,7 +31,7 @@ yielding.
 
 Visually, the overhead might look something like this:
 
-![Yield Overhead](images/yield_overhead.png)
+![Yield Overhead](../images/yield-overhead.png)
 
 This overhead can **disincentivize script from yielding**, which can lead to
 unresponsiveness in apps.
@@ -71,7 +71,7 @@ async function doWork() {
 ```
 
 There is an optional `priority` argument that works with the [prioritized
-postTask API](PrioritizedPostTask.md). If this argument is provided, the
+postTask API](prioritized-post-task.md). If this argument is provided, the
 Promise is resolved after tasks of the given priority and higher run.
 ```javascript
 let continuation = scheduler.yield('high');

YieldAndContinuation.md explainers/yield-and-continuation.md

@@ -6,7 +6,7 @@ testing this API in the wild (you can register [here](https://developers.chrome.
 
 This page tracks the current status of what parts of the APIs are implemented
 as part of the trial. Please read the
-[explainer](https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md)
+[explainer](./explainers/prioritized-post-task.md)
 to understand how to take advantage of these APIs.
 
 In addition to participating via the origin trial, these APIs are available on
@@ -35,8 +35,7 @@ The minimum supported Chrome version for `onprioritychange` and `currentTaskSign
 
 2. `TaskController` and `TaskSignal` have been implemented.
 
-3. [Priority
-   inheritance](https://github.com/WICG/main-thread-scheduling/blob/master/PostTaskPropagation.md)
+3. [Priority inheritance](./explainers/post-task-propagation.md)
    has been implemented and exposed through `scheduler.currentTaskSignal`.
 
 4. An `onprioritychange` event has been added to `TaskSignal`.
@@ -45,7 +44,7 @@ The minimum supported Chrome version for `onprioritychange` and `currentTaskSign
 
 Sample code can be found [here](sample-code/), which covers the currently
 implemented features. Please see the
-[explainer](https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md)
+[explainer](./explainers/prioritized-post-task.md)
 for more context.
 
 TODO(shaseley): add examples for `scheduler.currentTaskSignal` and `onprioritychange`.

images/current_scheduling_model.png images/current-scheduling-model.png

@@ -17,7 +17,7 @@ <h3>postTask Example: Delayed Tasks</h3>
       // The API takes an optional argument for 'delay', which is essentially makes
       // postTask act like a prioritized version of setTimeout. The semantics are
       // described in the explainer:
-      // https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md#posting-delayed-tasks
+      // https://github.com/WICG/scheduling-apis/blob/master/explainer/prioritized-post-task.md#posting-delayed-tasks
       results.push(scheduler.postTask(() => 'hello!', {delay: 1000}));
       results.push(scheduler.postTask(() => 'scheduled'));
       results.push(scheduler.postTask(() => 'world,'));