Preferred Mentor-Mentee Communication, Plan for Auto-Beaming Project

[Jason Yip]

Hi Carl,

I'm CC'ing the developers mailing list, just to let you know.

I would like to first ask you about your preferred mode of 
communication, if my project proposal is selected. That is, what modes 
of communication would you prefer for:

 * Real-time communication for mentor-mentee matters
 * Quick/casual communication among all the developers concerning my
   general project progress
 * Communication concerning bug reports, code reviews, etc. related to
   my project, whether it be casual or for the general public

Secondly, I have drafted a 12-week plan to go with my proposal 
(hopefully the markdown formats nicely):

- Weeks 0-3 (May 29-Jun 16)
    - Implement regular note subdivision beaming functionality/C++ 
class structures
    - Learn other C++ components that integrate with beam/subdivision code
    - Modify enough Scheme code to work with new code
    - Work on changing a few but critical test cases that work with my 
rewritten code if necessary
- End of Week 3 (Jun 16)
    - C++ Code infrastructure for regular note subdivision should be 
complete (obviously can't be 100% perfect)
    - Scheme code should have basic refactoring
    - Documentation covering beaming should be modified to align with 
my code by this point, but I may need the next few weeks to complete 
this part of the documentation
- Weeks 4-6 (Jun 19 - Jul 7)
    - Personal Vacation during weeks 5-6 (Jun 26 - Jul 7), so workload 
will be reduced
    - Ensure that my fixed code resolves most common complaints from 
old GitLab issues affected by this bug/backward compatibility
    - Rewrite/refactor the most important/critical regression tests
    - Wrap up refactoring/editing Scheme code
    - Make my code compliant with the music notation rules set by 
Elaine Gould's *Behind Bars* textbook if needed
- End of Week 6 (Jul 7)
    - All necessary changes to scheme code should be done
    - At least 50% of test cases/regression tests concerning beaming 
should pass
    - Output should be consistent with music notation rules outlined in 
*Behind Bars*
- Week 7 (Jul 10-Jul 14)
    - Midterm Evaluations
    - Consider issues branching from the main issue and whether my 
project will be able to solve them on time
    - Work on below if have time
- Weeks 7-9 (Jul 10-Jul 28)
    - Write regression tests for the new capabilities my project brings 
(mostly for regular note beaming, some for tuplet beaming)
    - Work on rewriting documentation concerning beaming
    - Perform necessary modifications to `convert-ly` rules
    - Start working on tuplet beaming if have time
- End of Week 9 (Jul 28)
    - Documentation concerning regular note beaming for developers and 
general public should be finished
    - Continuous integration tests with refactored code should pass
    - `convert-ly` rules should be correctly working for regular note 
beaming
    - All test cases for regular note beaming should be finished
- Week 10-12 (Jul 31-Aug 18)
    - Traveling/Moving during Week 12, so workload will be reduced 
during week 12
    - Work on tuplet beaming
    - Work on resolving as many GitLab issues related to regular note 
beaming
        - Add more test cases/regression tests, documentation 
explanations, etc.
- End of Week 12 (Aug 18)
    - Tuplet beaming should be mostly correct
        - May not be able to pass test cases/regression tests that 
strain tuplet beaming capabilities
        - Its `convert-ly` rule should be correct at least
- Week 13 (Aug 21-25)
    - My university term starts this week, reduced work
    - Assess remaining work that the project cannot finish on time
        - Write additional code comments/documentation/reg test ideas 
for work to be finished in the future

Do you or any other developers have any thoughts and feedback on the 
feasibility or structure of my plan? Its a large 350 hour project to be 
done in 10 full-time weeks (about 30-32 hrs/wk) and 3 part-time weeks 
(about 10-20 hrs/wk). Plan's start/end dates align with Google's 
timeline for GSoC.

I appreciate any feedback and support you can give me!


--
- Jason Yip

OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature