@item
@ref{Help us}: your assistance is requested.
+@item
+@ref{Sponsoring}: financial contributions.
+
@item
@ref{Development}: for contributors and testers.
+@item
+@ref{GSoC}: list of projects for Google Summer of Code.
+
@item
@ref{Authors}: the people who made LilyPond what it is today.
* Tiny examples::
* Bug reports::
* Help us::
+* Sponsoring::
* Development::
+* GSoC::
* Authors::
* Publications::
* Old news::
@divEnd
+@divClass{column-right-bottom}
+@subheading Sensitive emails
+
+Private matters should be sent to Graham Percival (project
+manager), who will discuss it with those concerned.
+
+@divEnd
@node Tiny examples
@node Bug reports
@unnumberedsec Bug reports
+
+@divClass{heading-center}
+If you have input that results in a crash or wrong output,
+then that is a bug.
+@divEnd
+
@divClass{column-center-top}
@subheading Step 1: Known bugs
-If you have input that results in a crash or an erroneous output,
-then that is a bug. There is a list of current bugs on our google
-bug tracker,
+We may already know about this bug. Check here:
@example
@uref{http://code.google.com/p/lilypond/issues/list}
@divClass{column-left-bottom}
@subheading Step 2: Creating a bug report
-If you have discovered a bug which is not listed, please help us
-by creating a bug report.
+If you have discovered a bug which is not listed,
+please help us by creating a bug report.
-@warning{We only accept bug reports in the form of
-@ref{Tiny examples}. We have very limited resources to deal with
-bug reports, so any non-minimal example will be rejected. Almost
+@warning{We only accept reports in the form of
+@ref{Tiny examples}. We have very limited resources,
+so any non-minimal example will be rejected. Almost
every bug can be demonstrated in four notes or less!}
Here is an example of a good bug report:
@divClass{column-center-bottom}
@subheading Step 4: Wait for a response
-Once your bug has been sent to the list, our Bug Squad will
-examine the report. Please allow up to 24 hours, as we have a
-limited number of volunteers for this task. They may ask you for
-more information, or may add the report to the tracker and let you
-know what the issue number is.
+Once your bug report has been sent to the list, our Bug Squad will
+examine it; they may ask you for more information. You will be notified
+when the report will be added to the bug tracker. Please allow up to 4 days,
+as we have a limited number of volunteers for this task.
-You may mark the bug so that you automatically receive emails when
+Once a bug has been added to the tracker, you can comment it to add
+more information about it.
+You may also mark the bug so that you automatically receive emails when
any activity on the bug occurs. This requires you have a google
account.
@divEnd
@divClass{column-left-top}
@divClass{keep-bullets}
-@helpusTasks
+@helpusSimple
@divEnd
@divEnd
@divClass{column-right-top}
-@helpusProjects
+@helpusAdvanced
@divEnd
+@node Sponsoring
+@unnumberedsec Sponsoring
+
+@divClass{keep-bullets}
+@divClass{column-left-top}
+@subheading Bounties
+
+In the past,
+
+@itemize
+@item some users have paid for new features
+@item some developers have added new features for hire
+@end itemize
+
+The LilyPond project does not organize such efforts; we neither
+endorse nor discourage such agreements. Any contracts between
+private individuals is the business of those individuals, not
+ours.
+
+@divEnd
+
+@divClass{column-right-top}
+@subheading Guidelines
+
+Any user wanting to offer money in exchange for work should bear
+in mind the following points:
+
+@itemize
+@item
+LilyPond developers may advertise their services on the lilypond
+email lists from time to time.
+
+@item
+Any agreements between private individuals should include the
+normal precautions when conducting business: who pays, how much do
+they pay, with what method of payment, and upon what set of
+conditions. We suggest that any ambiguity or uncertainty in these
+questions should be resolved before any work begins.
+
+@end itemize
+
+@divEnd
+
+@divClass{column-center-bottom}
+@subheading Interested developers
+
+Here is a list of people who have expressed an interest in
+bounties. Note that the amount of work done by individuals varies
+quite a bit throughout the years. We do not guarantee that this
+list is up-to-date, nor do we guarantee that the people listed
+here have any ability. The only criteria is "XYZ asked to be
+listed on this page".
+
+Looking at the git history is a good way to determine who the most
+active and experienced developers are. Statistics up to version
+@versionDevel{}:
+
+@multitable @columnfractions .3 .3 .3
+@item @uref{http://lilypond.org/~graham/gitstats-all/, overall history}
+@tab @uref{http://lilypond.org/~graham/gitstats-1year/, past year}
+@tab @uref{http://lilypond.org/~graham/gitstats-3months/, past three months}
+@end multitable
+
+Interested developers:
+@table @asis
+@item @email{dak@@gnu.org, David Kastrup}
+Donations are required to let me continue my current fulltime work on
+LilyPond. I focus on user and programmer interface design, coherence,
+implementation, simplification, documentation, and debugging.
+
+@c Format
+@c @item @email{name@@adress.domain, Name}
+@c area of interest (256 chars max)
+
+@end table
+
+@divEnd
+@divEnd
+
+
@node Development
@unnumberedsec Development
+@node GSoC
+@unnumberedsec GSoC
+
+@divClass{column-center-top}
+@subheading What is Google Summer of Code?
+
+Quoting
+@uref{http://www.google-melange.com/gsoc/homepage/google/gsoc2012, GSoC website},
+@qq{Google Summer of Code is a global program that offers students
+stipends to write code for open source projects. Google has worked
+with the open source community to identify and fund exciting projects
+for the upcoming summer.}
+
+The LilyPond Team decided that this is an excellent opportunity to find
+new contributors, encourage students already participating in LilyPond
+development to become more involved, and - last but not least - write some
+great code for the benefit of all!
+
+In addition to getting paid for your work, you'll gain experience in
+software development, which many of previous GSoC students describe as
+@emph{invaluable} (and you'll get a t-shirt, too!).
+
+If you have any questions, read
+@uref{http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs, GSoC FAQ}
+or contact us at @code{lilypond-devel@@gnu.org}.
+
+@divEnd
+
+@divClass{column-center-bottom}
+@subheading Our Ideas List
+
+Below is a list of projects suggested for GSoC students. If you don't
+see a project that suits you, feel free to contact us and suggest your own!
+It's also possible to scale down a project if you feel it's too big.
+
+We require that every student has basic @code{git} knowledge, and
+recommend that everyone applying for projects other than the last one
+have basic music notation knowledge.
+
+@subheading Grace notes
+
+Fix problems with synchronization of grace notes,
+together with all underlying architecture (see
+@uref{http://code.google.com/p/lilypond/issues/detail?id=34, issue 34 in our tracker}).
+Grace notes are confusing to LilyPond's timing because they're like
+going back in time. This causes weird effects, especially when one staff
+has a grace note and the other doesn't.
+
+@strong{Difficulty:} medium
+
+@strong{Requirements:} C++, MIDI
+
+@strong{Recommended:} familiarity with LilyPond internals
+
+@strong{Mentor(s):} Mike Solomon, Carl Sorensen
+
+@subheading MusicXML
+
+Adding comprehensive MusicXML export and improving import,
+together with tests checking that it works. Depending on time available,
+implement some or all of the following:
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Handle basic musical content export like the MIDI export (i.e. using
+dedicated exporter classes, derived from the translator class)
+
+@item
+Build the XML tree of the basic musical content,
+add a connection from music event to XML tag
+
+@item
+Let all LilyPond engravers do their job
+
+@item
+add ability to link each output object
+(basically each stencil / group of stencils) to the music cause
+(and thus to the XML tag in the XML tree)
+
+@item
+Add a XML output backend, which can then add the layout information
+for each output object to the XML tags
+
+@end itemize
+@divEnd
+
+The goal will be considered achieved when a (previously chosen) score could be
+imported from MusicXML and exported back with no unintentional loss of data.
+
+@strong{Difficulty:} medium
+
+@strong{Requirements:} MusicXML, Python, basic LilyPond knowledge
+
+@strong{Mentor(s):} Reinhold Kainhofer, Mike Solomon
+
+familiarity with other scorewriters (for cross-testing) would be a nice bonus.
+
+@subheading Improve slurs and ties
+
+The default shape of slur and tie curves is often unsatisfactory.
+Ties on enharmonic notes @code{@{ cis'~ des' @}} are not supported,
+ties "broken" by clef or staff change aren't supported well.
+The project includes collecting and sorting examples of bad output,
+deciding on the intended output and writing the actual code.
+
+@strong{Difficulty:} hard
+
+@strong{Requirements:} C++, experience with writing heuristics
+
+@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
+
+@strong{Mentor(s):} Mike Solomon
+
+@subheading Adding special variant of font glyphs
+Adding on-staff-line, between-staff-line, shorter and narrower variants
+of some glyphs, for example accidentals, together with a generic
+infrasctucture to support them. An example is ancient notation breve notehead
+coming in two variants, with smaller and bigger hole.
+
+@strong{Difficulty:} easy
+
+@strong{Requirements:} MetaFont, C++, good eye for details
+
+@strong{Recommended knowledge:} basic LilyPond knowledge
+
+@strong{Mentor(s):} Werner Lemberg
+
+@subheading Improve beaming
+
+Default positioning of regular, cross-staff, broken and kneed beams
+should be improved. Beaming should depend on context and neighbor notes (see
+@uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf, section 2.2 here}).
+If possible, reduce beaming computation time.
+
+@strong{Difficulty:} medium
+
+@strong{Requirements:} C++, experience with writing heuristics
+
+@strong{Recommended knowledge:} aesthetic sense
+
+@strong{Mentor(s):} Mike Solomon, Carl Sorensen
+
+@subheading Better tablature support
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+non-monotonic string tunings, like Ukulele
+
+@item
+create tablature input mode (currently musical information is entered
+in western-common-music-notation-terms, i.e. @qq{a quarter f sharp note}
+and then converted to tablature) for transcribing medieval lute tablature
+
+@item
+implement modern tablature features, such as bends, pull-off, hammer-on
+
+@item
+if a fretboard shape is defined for a given chord, use this information when
+displaying the chord on the staff (and not just display a default chord shape)
+
+@end itemize
+@divEnd
+
+@strong{Difficulty:} easy
+
+@strong{Requirements:} C++
+
+@strong{Recommended knowledge:} tablature notation familiarity
+
+@strong{Mentor(s):} Carl Sorensen
+
+@subheading Clean up various compilation warnings
+
+Clean up compiler warnings, static code analysis, and valgrind warnings.
+Automatic code analysis tools (warnings in @code{g++} and @code{clang})
+and analysis tools like valgrind memory leak detection and callgrind code
+profilers provide valuable information about possible flaws in C++ code.
+Cleaning these warnings would allow us to automatically reject any patch
+which introduced extra warnings.
+
+@strong{Difficulty:} medium
+
+@strong{Requirements:} C++
+
+@strong{Mentor(s):} Joe Neeman, Reinhold Kainhofer
+
+@divEnd
+
+
+
+
@node Authors
@unnumberedsec Authors
projects / lilypond.git / blobdiff