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

[Jason Yip]

Thanks for the feedback Carl!

See my comments below


On 2023-03-30 13:00, Carl Sorensen - c_sorensen(a)byu.edu wrote:
> 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.
I am open to use Matrix/Element for messages, Jitsi Meet for video 
conferencing. I've never used IRC before, but since Lilypond has a 
developers IRC channel, I can spend some time learning how to use it.

Using SMS or phone call may pose problems as my Week 5-6 vacation will 
be overseas. I'm fine using SMS/phone calls/Discord, but I see them as 
convenient fallback communication modes and would rather avoid them for 
digital privacy reasons.

>   * 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.
I intended to group beaming and subdivision functionality together, 
sorry for typo. I may have not made it clear that the items under the 
Week 7-9 bullet point also happen at the same time as Week 7 bullet 
point's items. It's just that Week 7 is a special week as the half-way 
point.
> 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
New modifications to my plan:

- 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
    - Adapt Scheme code to work with my newly-defined properties
- Week 3 (Jun 12-Jun 16)
    - Draft a basic plan/idea for tuplet beaming/subdivision given that 
I would be familiar enough with implementing regular note 
subdivision/beaming concepts at this point
    - Start rewriting/refactoring the most important/critical 
regression tests for regular note beaming/subdivision
- End of Week 3 (Jun 16)
    - C++ Code infrastructure for regular note subdivision should be 
complete (obviously can't be 100% perfect)
    - Scheme code refactoring to adapt to new Beam properties should be 
finished
    - NR Documentation covering regular note auto beaming should be 
finished, but may need expansion for tuplet subdivision/beaming
- Weeks 4-6 (Jun 19 - Jul 7)
    - Personal Vacation during weeks 5-6 (Jun 26 - Jul 7), so workload 
will be reduced
    - Wrap up regular note subdivision/beaming code
    - Ensure that my fixed code resolves most common complaints about 
regular note subdivision/beaming from old GitLab issues affected by this bug
    - Work on writing/refactoring regression tests
    - Start implementing tuplet subdivision/beaming functionality
- End of Week 6 (Jul 7)
    - My code should have made good progress on passing regression 
tests concerning regular note beaming should pass
    - Most GitLab issues concerning regular note beaming issue should 
be fixed or at least addressed
- 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
- Weeks 7-9 (Jul 10-Jul 28)
    - Fix bugs in regular note subdivision/beaming to pass regression tests
    - Perform necessary modifications to `convert-ly` rules
    - Add/modify regression tests for tuplet subdivision/beaming
    - Keep working on tuplet subdivision/beaming if have time
- End of Week 9 (Jul 28)
    - Regular note subdivision/beaming code should be finished/mostly 
approved by the other developers
    - `convert-ly` rules should be accurate for my new regular/tuplet 
subdivision/beaming code
    - Documentation concerning regular note beaming for developers and 
general public should be finished
    - All regression tests for regular note beaming should be finished 
and my code should mostly pass them
- Week 10-12 (Jul 31-Aug 18)
    - Traveling/Moving during Week 12, so workload will be reduced 
during week 12
    - Work on tuplet subdivision/beaming code and documentation
- 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` rules 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

Hopefully this new plan is more realistic. Week 10 and onward don't have 
much deliverables to account for possibility of progress delays (and I 
would have busy personal schedules during weeks 12-13).

> 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

I plan to submit a first draft of my GSoC application in a few hours. 
Hopefully, you and other Lilypond developers would be able to see it and 
leave feedback.

Again, thank you for the feedback!

--
- Jason Yip

OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature