diff --git a/proposal b/proposal
index de751da..6ed42e0 100644
--- a/proposal
+++ b/proposal
@@ -21,7 +21,7 @@ E-mail: shyamthakkar001@gmail.com
 Ph. No.: +91 7990974044
 
 Education: L.D. College of Engineering, Gujarat, India
-Year: IV
+Year: IV (Final Year)
 Degree: Bachelors in Electronics and
         Communications Engineering
 
@@ -34,9 +34,10 @@ Overview
 
 Initially Git used to only rely on shell scripts to test the functionality
 usually deemed to be internal (e.g. libraries, functions etc.) This was achieved
-through t/helper binaries which would take input via stdin and output through
-stdout and the test scripts would consume those outputs. This translation is
-costly due to the following reasons:
+through t/helper binaries which would take input via stdin or we can also invoke
+it from the command line via arguments and output through stdout and the test
+scripts would consume those outputs. This translation is costly due to the
+following reasons:
 
 - Each test script creates a new git repository which is many times not needed.
   See here[1] for example.
@@ -108,7 +109,9 @@ have made, in chronological order:
     This patch added functionality to assume an empty tree when on an unborn
     branch to be able to use ‘restore –staged’. However, this was discontinued
     due to lack of community interest. In hindsight, I think that this would
-    have been an acceptable patch, had I described it well.
+    have been an acceptable patch, had I described it well. However, I might
+    pick this up again during the empty period of present till the start of
+    GSoC.
     Mailing list thread:
     https://lore.kernel.org/git/20240206230357.1097505-2-shyamthakkar001@gmail.com/
 
@@ -250,6 +253,34 @@ per week during the Community Bonding and Coding Phase. This may fluctuate
 depending on the type of test. Some of those tests are already being worked on
 by Achu Luma.
 
+- Tests which might not be suitable for migration:
+  As already mentioned in the Additional Notes section, some tests are not worth
+  migrating. This is because some of these helper binaries provide general
+  purpose utilities which are used in not just unit tests, but used elsewhere
+  as well. An example of that would be test-ref-store.c. Just by grepping for
+  ‘test-tool ref-store’, we can see that it is used in many test scripts which
+  also include end-to-end tests. More examples of these would be test-genzeros
+  and test-genrandom.
+
+- Tests which might be suitable for migration:
+  On the other hand, a suitable candidate for the migration would generally just
+  provide a certain output and that output is compared against an expected
+  value. These would not include utility helpers as mentioned above. In these
+  cases, the test script is usually just a layer to compare the output with the
+  expected value, and has little test related logic in itself.
+  test-example-decorate.c seems like a good straight-forward choice as their
+  “BUG” calls can be replaced by test_msg calls in the new framework and their
+  corresponding if conditions can become checks in the new framework. Also, this
+  helper is not used anywhere besides a single call in t9004. Some more examples
+  would be test-revision-walking.c (t0062), and while 
+  test-{oidmap, oidtree, hashmap}.c can be considered a bit large, those are
+  very similar in nature to what I have already implemented for test-oidarray.c.
+  And the majority of these outlined tests have been stable for a long time and
+  have not had any meaningful change. Therefore, I would like to start with
+  these tests with mentors’ consensus. Some other tests can also be identified
+  with the help of mentors and those can also be done instead of the ones I
+  outlined.
+
 ----Timeline----
 
 Pre-GSoC
@@ -294,8 +325,28 @@ have not setup the blog yet, it will be at:
 ----Availability----
 
 My current semester ends on 30th April and my exam/viva is tentatively on 7th
-May. After that I have freed my summer for GSoC, therefore I will be able to
-give a minimum of 35-40 hours per week.
+Mayand I will graduate after the results are out in June. Therefore I will be
+able to give a minimum of 35-40 hours per week after 7th May as I have not taken
+up any responsibilities in the summer for the purpose of GSoC.
+
+----Stretch Goals----
+
+These goals may not be achieved during the GSoC period, however, these may come
+in handy if the migration is done ahead of the schedule or it is determined that
+the number of tests that need to be migrated are not sufficient to cover the
+allocated GSoC period further down the line. These can also be done after the
+GSoC period. (Note that these are just personal observations/ideas and may not
+be accepted by mentors, hence '_Stretch_ Goals'.)
+- Enhancement of the unit testing library. An example of the need of doing this
+  would be t-ctype, which bypasses top-level macros such as TEST(), in favor of
+  custom logic with the use of internal helper functions.
+- Add more helper functions in the unit testing library such as handling and use
+  of parameters defined by environment variables (which I personally faced in
+  implementing t-oidarray.) I am sure there are other such utilities which might
+  be worthwhile.
+- Adding support for performance related testing through unit tests.
+- Working in other areas of the codebase not related to unit testing or doing
+  other tasks as specified by mentors.
 
 Post-GSoC
 ---------
