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

[Carl Sorensen]

Thanks, Jason.

See my answers below.

Carl

From: Jason Yip <sripedia_getpgrp@slmail.me>
Date: Wednesday, March 29, 2023 at 8:45 PM
To: Carl Sorensen <carl.d.sorensen@gmail.com>
Cc: Devel <lilypond-devel@gnu.org>
Subject: Preferred Mentor-Mentee Communication, Plan for Auto-Beaming Project

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
I would probably prefer phone or text, but can use Discord, IRC, or various 
videoconferencing systems.  I prefer phone or text because I typically always 
have my phone with me but I’m not always at my computer.  But I’m willing to 
work out something that will work with you.

  *   Quick/casual communication among all the developers concerning my general 
project progress
Lilypond-devel mailing list

  *   Communication concerning bug reports, code reviews, etc. related to my 
project, whether it be casual or for the general public
Liliypond-devel mailing list
If these answers aren’t good for you, let’s have more of a conversation.

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

This schedule seems a bit over-aggressive.  But I think it’s good for a stretch 
goal.

- 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

I haven’t looked at it carefully, but I think that the Scheme code just calls 
beaming-pattern.cc to do the hard work of beaming patterns, so I think that by 
and large fixing the C++ will fix the beaming subdivision problems.

There will likely need to be some new properties defined (that will involve 
some Scheme procedures.
    - Work on changing a few but critical test cases that work with my 
rewritten code if necessary

I’d have you make sure that you have failing regression tests for all of the 
beaming features you hope to implement.  The regression tests will provide the 
best specification for success you could have.   And having them fail is no 
problem at this stage.

- End of Week 3 (Jun 16)
    - C++ Code infrastructure for regular note subdivision should be complete 
(obviously can't be 100% perfect)

I love that you are starting on regular note subdivision.  I think that’s a 
great starting point.

But I think you should have a vision for how tuplets are going to work before 
refactoring the regular beaming code.  You should have confidence that your 
code is compatible with your planned tuplet work.
    - 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

When you have the regression tests working, the documentation should be pretty 
straightforward.  In the NR, we don’t try to be a tutorial; we try to be a 
reference.  So basically we define a behavior that can be accomplished and show 
how it is done with a snippet.
- Weeks 4-6 (Jun 19 - Jul 7)
    - Personal Vacation during weeks 5-6 (Jun 26 - Jul 7), so workload will be 
reduced

Good for you scheduling a vacation!

    - Ensure that my fixed code resolves most common complaints from old GitLab 
issues affected by this bug/backward compatibility

This will be easily done by having your broken regression tests written earlier
    - Rewrite/refactor the most important/critical regression tests

IMO should have been done earlier.

    - 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

The notation rules should be implemented in the regression tests described 
earlier.

- 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

Adding new convert-ly rules is really important.  Thanks for making this part 
of your proposed work!

    - 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

If you wrote your initial regression tests for the current syntax, they’d be a 
great set of files for proving convert-ly rules.

    - 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

I haven’t seen when you started working on Tuplet beaming – ( I guess you said 
week 9 if you have time).  I wonder if weeks 10-12 will be enough time to get 
tuplet beaming fixed.

It would be hard to apply your changes if they made tuplet beaming worse.  But 
we could certainly apply your changes if they didn’t harm current behavior 
(tuplet beams generally work, but subdividisions do not).

        - 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!

I like your plan!

--

- Jason Yip