GSOC proposal critical feedback

Tue Apr 30 12:53:50 UTC 2013

On 29. 4. 2013 HARDIK Dhimmar wrote:
> *Proposal for Google Summer of Code - 2013 to KDE community (Amarok)*
> *Proposal Title:*
>             *Unified CUE File and Audiobook support in Amarok.***
> 
> *Brief Description:*
> 
>                         Amarok is a music player which has a very
> user-friendly interface and uses cue sheets which specifies track length
> and name. The aim of this proposal is to how I would go about in
> implementing Unified cue file and an audiobook chapter support feature in
> amarok.

This is very simplified. What does "uses" mean? What exactly does 
"implementing" mean in this context? How it will work in the end?

> *Motivation for project:*
> 
>                         Nowadays users are fond of hearing the book in an
> audio file and play music from local collection. In daily life, users are
> distracted with many other activities and tend to close the program or
> hibernate it,

Uhm, right, but it seems rather very loosely connected to this proposal.

> So we should provide a facility to user which can help
> him/her navigate in audiobook(via chapters)

Right.

> and resume it from where he/she
> had stopped before.

This is already working! We also automatically save playback markers for files 
longer then 10 minutes! Please do the research of existing functionality first.

> Amarok does not provides the support for cue files for
> local collection and also does not allow viewing information of chapter
> metadata for audiobooks.

Right.

> This is one of the important feature that should
> be provided to make amarok one of the best music player.

Arguable, but hey.

> *Implementation Detail: *
> 
>             I intend to implement two main features for Amarok:
> 
> Ø  Cue-sheet support for local collection and also in Ums collection.
> 
> Ø  Provide a TagLib extension which helps in extracting information of
> chapter metadata for audiobooks.

This would be more suited for "Project Goals" section. But you should be also 
more specific the the project goals section, stating what exactly will work 
when the project is finished and how that will be visible to the user.

>             I have gone through amarok and found that embedded cue works
> for the music files but not for the files present in the local collection.
> I have studied the bug:
> 
> *Bug 187587:  Cue sheet not working for files in collection (Very much
> similar to my project).*
> 
>             It provides us the information about implementing the embedded
> cue sheet support for local collection (also in Ums collection).
> 
> There would be a metadata file which stores the chapter information of an
> audio book. This would help me to implement a class in taglib which
> extracts the chapter metadata and design a user interface which provides
> the facility to navigate through different chapters.

Oh, oh, you seem to be intermixing the .cue file support with chapter reading 
support!

>             Due to my recent final semester exams and submission of ongoing
> projects, I could not contribute much to amarok. I would like to work and
> resolve following list of bugs:
> 
> Bugs that I observed:
> 
> *Bug Id:* *318790* - Local collection not updating if set directly to C:\
> [Windows] <https://bugs.kde.org/show_bug.cgi?id=318790>
> *Bug Id:* *319015* – Regarding displaying overall time of a song in a
> playlist.

I don't think it is worth to mention observed bugs in the proposal.

> Bugs related to my project:
> *Bug Id:* *187587* - cue sheet not working for files in collection.
> *Bug Id:* *240409* - Support for chapter navigation in M4B files.
> *Bug Id:* *286089* - failure to read the cue when spaces and
> other special characters in the name of the file.
> *Bug Id:* *233283* - Bumpy song transitions when listening to cuesheeted
> music.

Right.

> *Tentative Timeline:*
>             Before 25th May:  Implement the support for Bollywood(Hindi
> Film Industry) song’s lyrics and try to solve the bugs that I reported and
> are related to my project, which in turn helps me to understand the source
> code and get me familiarize with amarok.
> 
>             May28-June16: (Research phase) Understand the implementation of
> cue-sheeted music and how would I go about implementing the chapters
> feature in audiobook in amarok.

This would even fit better before actually submitting this proposal.

> June17-July20: (Persistence phase) Implement the cue-sheeted music and
> chapter-enabled audiobooks for local collection before commencement of my
> next semester.

We expect per-week timeline, this is way too coarse.

> July20-August2 :( Mid-Term Evaluations) Evaluation of my work till now.
> Getting mentor advice and get the direction on how to go about further.

Hmmm, mentor can of course help with problems and review your proposed ideas, 
but the general direction should be done by the student, this is not just 
doing what mentor said should be done.

> August2-August18: (Solving Bugs) Solve the bugs and implement other
> features if needed as suggested by the mentor.

Again, mentor cannot tell you directly what to do.

> August18-September1 :( Integration Phase) Testing the implemented feature
> and test other modules which are related to it.

This is rather vague.

> September2- September8 :( Review process) Reviewing the whole code and make
> the product deployable.

Ugh, what does this mean, "make product deployable"?

> September8- September15 :( Documentation Phase) Making necessary documents
> as required for understanding my work.

The code should be documented as it is written, not after in a batch.

> After September15: Discussing with mentor about the final submission and
> evaluation of code and talk about what other features we can add to make
> even better amarok.

This is another very general point - we expect much more specific ideas in the 
proposal!

> *Q: Do you have other obligations in the GSoC period (school, work,
> vacation, etc.)?*
> 
> I am doing research internship from 13th may to 29th June which
> would take 1 hour a day dedication i.e. 7 hours a week. I can dedicate the
> following time for GSOC:
> 
> 28th may-30th June: 6 hours a day i.e. 6*7=42 hours/week
> 5th July- 28th July: 7 hours a day i.e. 7*7=49 hours/week
> 
> As next semester commences. I intend to devote more time on weekends to
> keep up with the project.
> 
> From 28th July:
> Weekdays: 4-5 hours a day i.e. 5*5=   25 hours
> Weekend: 8 hours a day i.e. 8*2=        *16 hours *
>                                                   41 hours/week

Hehe, this is maybe too detailed. :-) This is somewhat unfortunate that many 
Indian universities apparently start in early August, while GSoC has been 
somewhat shifter further. :-|

> *About me (Let us know who you are!):*
> 
> I am Hardik Dhimmar pursuing bachelor’s degree (presently
> in 3rdyear) from Dhirubhai Ambani Institute of Information and
> Communication Technology (DA-IICT). I am very eager to contribute to open
> source community.
> 
> I have decent understanding of amarok and its source code. I
> have already built its source code and played with it (make changes in the
> function) to know the impact of it on amarok music player.

Um, from the description above I wouldn't exactly call it "decent 
understanding". Note that other students have actually fixed real bugs, not 
just played with the code and seeing something happens.

> Following are the skills which will help me to pursue the project:
> Languages Known
> C,C++,Java, Python(basic), PyOpenGL
> Operating Systems
> Arch Linux, Ubuntu(11.04 and later),Linux Mint Windows: XP,7 and 8
> Web Knowledge
> HTML, CSS, JavaScript, PHP, Ajax
> 
> *Why should you select me?*
> 
>             I don’t have too much contribution towards open source till now
> but have the required skills to complete the project. I have developed a
> full working website for a school located in Ahmedabad (in Gujarat, India)
> according to Software Engineering principals(*making proposal, SRS
> {Software Requirement Specification}, SDS {Software Design Specification},
> Test cases and necessary documents).* This provided me with the experience
> of how to go along with the project and what difficulties are faced during
> the path of final delivering of the project.
> 
>             I have learnt and applied necessary programming techniques
> needed for the project:
> (...)

> Ø  Operating System: *Disk Cache Scheduling*-* Implemented a Kernel level
> thread and also made a basic system call.

Oh, interesting. Is the code public/can you show it?

>              Now I am ready to implement my thoughts and in the upcoming
> days, I will submit my implemented feature in amarok by 25th may.

Which one?

> *I have submitted the following bugs in amarok:*
> 
> Regarding Local collection update
> https://bugs.kde.org/show_bug.cgi?id=318790
> 
> For Video player(not been able to close) used by amarok
> https://bugs.kde.org/show_bug.cgi?id=318813
> 
> Audio file with different extension is not displaying overall time of a
> song.
> https://bugs.kde.org/show_bug.cgi?id=319015

Sorry, while bug reports are really useful from users, we cannot consider them 
as a significant contributions from students that want to spend summer with 
coding on Amarok.

Unfortunately, the proposal looks rather half-done to me, it needs more 
thought on how this will be actually implemented and perhaps more research of 
the involved technologies/software parts etc.

	Matěj