add your solutions

Signed-off-by: Alex Chi <iskyzh@gmail.com>

README.md

@@ -14,6 +14,10 @@ You may join skyzh's Discord server and study with the mini-lsm community.
 
 [![Join skyzh's Discord Server](https://dcbadge.vercel.app/api/server/ZgXzxpua3H)](https://skyzh.dev/join/discord)
 
+**Add Your Solution**
+
+If you finished at least one full week of this tutorial, you can add your solution to the community solution list at [SOLUTIONS.md](./SOLUTIONS.md). You can submit a pull request and we might do a quick review of your code in return of your hard work.
+
 ## Development
 
 ```

SOLUTIONS.md

@@ -0,0 +1,11 @@
+# Mini-LSM Community Solutions
+
+You can add your solution to this page once you finish any full week of the tutorial. You may have a one-sentence introduction of what you have done in your solution and any special functionalities you have implemented.
+
+## Week 1
+
+## Week 2
+
+## Week 3
+
+* [skyzh/mini-lsm-solution-checkpoint](https://github.com/skyzh/mini-lsm-solution-checkpoint): The author's solution of Mini-LSM.

mini-lsm-book/src/week3-01-ts-key-refactor.md

@@ -3,6 +3,7 @@
 In this chapter, you will:
 
 * Refactor your implementation to use key+ts representation.
+* Make your code compile with the new key representation.
 
 ## Task 0: Use MVCC Key Encoding
 

mini-lsm-book/src/week3-02-snapshot-read-part-1.md

@@ -1,5 +1,12 @@
 # Snapshot Read - Memtables and Timestamps
 
+In this chapter, you will:
+
+* Refactor your memtable/WAL to store multiple versions of a key.
+* Implement the new engine write path to assign each key a timestamp.
+* Make your compaction process aware of multi-version keys.
+* Implement the new engine read path to return the latest version of a key.
+
 During the refactor, you might need to change the signature of some functions from `&self` to `self: &Arc<Self>` as necessary.
 
 ## Task 1: MemTable, Write-Ahead Log, and Read Path

mini-lsm-book/src/week3-03-snapshot-read-part-2.md

@@ -1,12 +1,16 @@
 # Snapshot Read - Engine Read Path and Transaction API
 
-## Task 1: Store Largest Timestamp in SST
+In this chapter, you will:
 
-## Task 2: Recover Commit Timestamp
+* Finish the read path based on previous chapter to support snapshot read.
+* Implement the transaction API to support snapshot read.
+* Implement the engine recovery process to correctly recover the commit timestamp.
 
-## Task 3: Lsm Iterator with Read Timestamp
+At the end of the day, your engine will be able to give the user a consistent view of the storage key space.
 
-## Task 4: Multi-Version Scan and Get
+## Task 1: Lsm Iterator with Read Timestamp
+
+## Task 2: Multi-Version Scan and Get
 
 For now, inner = `Fused<LsmIterator>`, do not use `TxnLocalIterator`
 
@@ -14,6 +18,10 @@ explain why store txn inside iterator
 
 do not implement put and delete
 
+## Task 3: Store Largest Timestamp in SST
+
+## Task 4: Recover Commit Timestamp
+
 ## Test Your Understanding
 
 * So far, we have assumed that our SST files use a monotonically increasing id as the file name. Is it okay to use `<level>_<begin_key>_<end_key>_<max_ts>.sst` as the SST file name? What might be the potential problems with that?