1 Elu@c -*- coding: utf-8; mode: texinfo; -*-
5 This chapter deals with defects, feature requests, and
6 miscellaneous development tasks.
9 * Introduction to issues::
11 * Issue classification::
12 * Adding issues to the tracker::
14 * Summary of project status::
18 @node Introduction to issues
19 @section Introduction to issues
21 @warning{All the tasks in this chapter require no programming skills and
22 can be done by anyone with a web browser, an email client and the
23 ability to run LilyPond.}
25 The term @q{issues} refers not just to software bugs but also includes
26 feature requests, documentation additions and corrections as well as any
27 other general code @q{TODOs} that need to be kept track of.
31 @section The Bug Squad
35 * Bug Squad checklists::
38 To help keep track and organize all issues are a group of tireless
39 volunteers collectively known as the @emph{Bug Squad}. Composed mainly
40 of non-programmers, the Bug Squad's responsibilities include:
45 Monitoring the LilyPond Bugs mailing list looking for any issues
46 reported by other users ensuring that they are accurate and contain
47 enough information for the developers to work with, preferably with
48 @rweb{Tiny examples} and if applicable, screenshots.
51 Adding new issues to the @emph{issue tracker} or updating existing
52 issues with new information.
55 Verifying issues in the @emph{issue tracker} that have been marked
56 as @q{fixed}; making sure either that the fix works or (in the case of
57 Documentation for example) has at least been commited to the code base.
61 The @ref{Meisters, Bug Meister} also helps check the current
62 @ref{Regression tests} and highlights any significant changes (or
63 problems) since the previous LilyPond release.
65 If you would like to be part of the Bug Squad, please contact the
66 @ref{Meisters, Bug Meister}.
70 @subsection Bug Squad setup
72 We highly recommend that you configure your email to use effective
73 sorting; this can reduce your workload @emph{immensely}. The
74 email folders names were chosen specifically to make them work if
75 you sort your folders alphabetically.
80 Read every section of this chapter, @ref{Issues}.
83 If you do not have one already, create a gmail account and send
84 the email address to the @ref{Meisters, Bug Meister}.
87 Subscribe your gmail account to @code{bug-lilypond}.
90 Configure your google code account:
95 Wait until your gmail account is listed in:
98 @uref{http://code.google.com/p/lilypond/people/list}
102 Sign in to google code by clicking in the top-right corner of:
105 @uref{http://code.google.com/p/lilypond/issues/list}
108 You cannot log on if you have Google Sharing enabled
109 @uref{http://www.googlesharing.net/}.
112 Go to your @qq{Profile}, and select @qq{Settings}.
115 Scroll down to @qq{Issue change notification}, and make sure that
116 you have @emph{selected} @qq{If I starred the issue}.
121 Configure your email client:
126 Any email sent with your gmail address in the @code{To:} or
127 @code{CC:} fields should go to a @code{bug-answers} folder.
129 When setting up your filtering rules, be aware that Google Code
130 might use different versions of your email address, such as ones
131 ending in @code{@@googlemail.com} or @code{@@gmail.com}.
134 Any other email either from, or CC'd to,
137 lilypond@@googlecode.com
141 should go into a separate @code{bug-ignore} folder. Alternately,
142 you may automatically delete these emails.
144 You will @strong{not read} these emails as part of your Bug Squad
145 duties. If you are curious, go ahead and read them later, but it
146 does @strong{not} count as Bug Squad work.
149 Any other email sent to (or CC'd to):
156 should go into a separate @code{bug-current} folder.
163 @node Bug Squad checklists
164 @subsection Bug Squad checklists
166 When you do Bug Squad work, start at the top of this page and work
167 your way down. Stop when you've done 20 minutes.
169 Please use the email sorting described in @ref{Bug Squad setup}.
170 This means that (as Bug Squad members) you will only ever respond
171 to emails sent or CC'd to the @code{bug-lilypond} mailing list.
174 @subsubheading Emails to you personally
176 You are not expected to work on Bug Squad matters outside of your
177 20 minutes, but sometimes a confused user will send a bug report
178 (or an update to a report) to you personally. If that happens,
179 please forward such emails to the @code{bug-lilypond} list so that
180 the currently-active Bug Squad member(s) can handle the message.
183 @subsubheading Daily schedule as of July 2015
186 Monday: Federico Bruni
187 Tuesday: Simon Albrecht
188 Wednesday: Simon Albrecht
189 Thursday: Colin Campbell
191 Saturday: Colin Campbell
196 @subsubheading Emails to @code{bug-answers}
198 Some of these emails will be comments on issues that you added to
202 If they are asking for more information, give the additional
206 If the email says that the issue was classified in some other
207 manner, read the rationale given and take that into account for
208 the next issue you add.
211 Otherwise, move them to your @code{bug-ignore} folder.
215 Some of these emails will be discussions about Bug Squad work;
219 @subsubheading Emails to @code{bug-current}
221 Dealing with these emails is your main task. Your job is to get
222 rid of these emails in the first method which is applicable:
226 If the email has already been handled by a Bug Squad member (i.e.
227 check to see who else has replied to it), delete it.
230 If the email is a question about how to use LilyPond, reply with
234 For questions about how to use LilyPond, please read our
235 documentation available from:
236 @uref{http://lilypond.org/website/manuals.html}
237 or ask the lilypond-user mailing list.
241 If the email mentions @qq{the latest git}, or any version number
242 that has not yet been officially released, forward it to
243 @code{lilypond-devel}.
246 If a bug report is not in the form of a Tiny example, direct the
247 user to resubmit the report with this response:
250 I'm sorry, but due to our limited resources for handling bugs, we
251 can only accept reports in the form of Tiny examples. Please see
252 step 2 in our bug reporting guidelines:
253 @uref{http://lilypond.org/website/bug-reports.html}
257 If anything is unclear, ask the user for more information.
259 How does the graphical output differ from what the user expected?
260 What version of lilypond was used (if not given) and operating
261 system (if this is a suspected cause of the problem)? In short,
262 if you cannot understand what the problem is, ask the user to
263 explain more. It is the user's responsibility to explain the
264 problem, not your responsibility to understand it.
267 If the behavior is expected, the user should be told to read the
271 I believe that this is the expected behaviour -- please read our
272 documentation about this topic. If you think that it really is a
273 mistake, please explain in more detail. If you think that the
274 docs are unclear, please suggest an improvement as described by
275 @qq{Simple tasks -- Documentation} on:
276 @uref{http://lilypond.org/website/help-us.html}
280 If the issue already exists in the tracker, send an email to that
284 This issue has already been reported; you can follow the
285 discussion and be notified about fixes here:
289 (copy+paste the google code issue URL)
292 Accept the report as described in
293 @ref{Adding issues to the tracker}.
297 All emails should be CC'd to the @code{bug-lilypond} list so that
298 other Bug Squad members know that you have processed the email.
300 @warning{There is no option for @qq{ignore the bug report} -- if
301 you cannot find a reason to reject the report, you must accept
306 @c Try omitting this from Bug Squad duties
308 @subheading Updates / discussion about issues
310 We try to keep discussions about issues on the tracker, but
311 sometimes it spills over onto email. If discussion has ended with
312 no patch / resolution and at least @strong{3 days} have passed,
318 Summarize the recent discussion on the tracker, and add a link to
319 the original discussion.
322 Add the comment @qq{there was some technical discussion which I
323 could not understand}, and include a link to the original
326 We do not expect Bug Squad members to be programmers, or even to
327 be moderately-skilled users. Your job is to keep track of issue
328 reports; it is @emph{perfectly acceptable} to not understand
329 discussions between advanced users and/or developers.
335 @subheading Regular maintenance
337 After @strong{every release} (both stable and unstable):
342 Issues to verify: go to
345 @uref{http://code.google.com/p/lilypond/issues/list?can=7}
348 (You can also generate this list by selecting
349 @qq{Issues to verify} from the drop-down list next to the search
352 You should see a list of Issues that have been claimed fixed by a
353 developer. If the developer has done their job properly, the
354 Issue should have a tag @qq{Fixed_mm_MM_ss}, where mm is
355 the major version, MM the minor version and ss the current
356 release. This will help you work out which you can verify - do
357 not verify any Issues where the claimed fixed build is not yet
358 released. Work your way through these as follows:
360 If the Issue refers to a bug, try to reproduce the bug with the latest
361 officially released version (not one you've built yourself from
362 source); if the bug is no longer there, mark the
363 issue @qq{Verified} (i.e. @qq{the fix has been verified to work}).
365 Quite a few of these will be issues tracking patches. @strong{You
366 do not have to prove these patches work - simply that they have
367 been pushed into the code base.} The developer should have put
368 information similar to @qq{Pushed as as
369 d8fce1e1ea2aca1a82e25e47805aef0f70f511b9} in the tracker. The
370 long list of letters and numbers is called the @qq{committish}.
371 Providing you can find this at the git tracker:
374 @uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git}
377 then you should mark the issue as verified. A quick way of
378 finding these is to enter the committish at the following address:
381 @uref{http://philholmes.net/lilypond/git/}
384 The Issue tracker also requires that any issues labelled as
385 @qq{Duplicate} are also verified. Check that the linked issue is
386 a duplicate and verify the issue.
388 A few (approximately 10%) of the fixed issues relate to the
389 build system or fundamental architecture changes; there is no way
390 for you to verify these. Leave those issues alone; somebody else
394 The official regression test comparison is online at:
396 @c NOTE: leave this here. In this case, it's worth duplicating
399 @uref{http://lilypond.org/test/}
402 If anything has changed suspiciously,
403 ask if it was deliberate. If the text output from LilyPond (the
404 logfile) changes, the differences will be displayed with a +
405 before text added to the logfile and - before any text removed
406 from the logfile. This may or may not be suspicious.
408 There is one test designed to produce output every time the
409 regtests are created. @code{test-output-distance.ly} creates
410 randomly spaced notes and will always have different output if the
411 regtest checker is working.
413 More information is available from in
414 @ref{Precompiled regression tests}.
417 Check for any incorrectly-classified items in the tracker. This
418 generally just means looking at the grid to see any items without
425 @c try omitting from daily tasks for now. -gp
427 @subheading Irregular maintenance
429 @warning{These tasks are a lot of work; gathering more volunteers
430 to help is definitely recommended. However, the Bug Squad should
431 handle the organization and training of new volunteers.}
433 Once every year or two:
438 Checking all regtests: although we have a system for checking the
439 regtests between two versions, occasionally a bug will slip
440 through the cracks. It is therefore good to manually examine all
441 the regtests (compare the images to the text description). More
442 information is available from in @ref{Regression tests}.
446 Checking all issues: we try to mark each Issue @q{fixed} when we
447 fix it, but occasionally one or two issues will slip through the
448 cracks. It is therefore good to check all Issues. If you see the
449 same (broken) output as the initial report, then simply post a
450 @qq{Problem still exists in 2.x.y} message to the issue.
457 @node Issue classification
458 @section Issue classification
460 The Bug Squad should classify issues according to the guidelines
461 given by developers. Every issue should have a Status and Type;
462 the other fields are optional.
464 @subheading Status (mandatory)
471 New: the item was added by a non-member, despite numerous warnings
472 not to do this. Should be reviewed by a member of the Bug Squad.
475 Accepted: the Bug Squad added it, or reviewed the item.
478 Started: a contributor is working on a fix. Owner should change
479 to be this contributor.
489 Invalid: issue should not have been added in the current state.
492 Duplicate: issue already exists in the tracker.
495 Fixed: a contributor claims to have fixed the bug. The Bug
496 Squad should check the fix with the next official binary release
497 (not by compiling the source from git). Owner should be set to
501 Verified: Bug Squad has confirmed that the issue is closed. This
502 means that nobody should ever need look at the report again -- if
503 there is any information in the issue that should be kept, open a
504 new issue for that info.
509 @subheading Owner (optional)
511 Newly-added issues should have @emph{no owner}. When a
512 contributor indicates that he has Started or Fixed an item, he
513 should become the owner.
516 @subheading Type (mandatory)
518 The issue's Type should be the first relevant item in this list.
523 Type-Critical: normally a regression
524 against the current stable version or the previous stable version.
525 Alternatively, a regression against a fix developed for the
526 current version. This does not apply where the
527 @qq{regression} occurred because a feature was removed
528 deliberately - this is not a bug.
530 Currently, only Critical items will block a stable release.
533 Type-Maintainability: hinders future development.
536 Type-Crash: any input which produces a crash.
539 Type-Ugly: overlapping or other ugly notation in graphical output.
542 Type-Defect: a problem in the core program. (the @code{lilypond}
543 binary, scm files, fonts, etc).
546 Type-Documentation: inaccurate, missing, confusing, or desired
547 additional info. Must be fixable by editing a texinfo, ly, or scm
551 Type-Build: problem or desired features in the build system. This
552 includes the makefiles, stepmake, python scripts, and GUB.
555 Type-Scripts: problem or desired feature in the non-build-system
556 scripts. Mostly used for convert-ly, lilypond-book, etc.
559 Type-Enhancement: a feature request for the core program. The
560 distinction between enhancement and defect isn't extremely clear;
561 when in doubt, mark it as enhancement.
564 Type-Patch: tracking a patch on Rietveld. Bug squad should not
565 need to use this label.
568 Type-Other: anything else.
573 @subheading Priority (mandatory)
575 Currently, only Critical items will block a stable release.
580 Priority-Critical: LilyPond segfaults, a regression (see below)
581 against a previous stable version or a regression against a fix
582 developed for this version. This does not apply where the
583 @qq{regression} occurred because a feature was removed
584 deliberately - this is not a bug.
587 Priority-High: An issue which produces output which does not
588 accurately reflect the input (e.g. where the user would expect
589 an accidental, but none is shown) or which produces aesthetically
590 poor output in a situation which could be expected to crop up
591 frequently in real-world music. It should not be used where the
592 problem can be avoided with a simple workaround. It can also
593 be used to flag where new code in a development version is not
594 functioning as it should. This level is also used for issues
595 which produce no output and fail to give the user a clue about
599 Priority-Medium: Normal priority - use this as the default.
602 Priority-Low: A minor problem which produces slightly undesirable
603 output, or which will only occur in contrived examples, or which
604 is very easily worked around.
607 Priority-Postponed: no fix planned. Generally used for things
608 which nobody wants to touch.
612 Note that these are initial classifications and can be subject
613 to change by others in the development team. For example, a
614 regression against an old stable version which hasn't been
615 noticed for a long time and which is unlikely to get fixed could
616 be downgraded from Priority-Critical by one of the programmers.
620 @subheading Opsys (optional)
622 Issues that only affect specific operating systems.
624 @subheading Patch label (optional)
626 Normal Bug Squad members should not add or modify Patch issues
627 except to verify them; for all other Patch work, leave them to the
633 Patch-new: the patch has not been checked for @qq{obvious}
634 mistakes. When in doubt, use this tag.
637 Patch-review: the patch has no @qq{obvious} mistakes (as checked
638 by the Patch Meister), and is ready for review from main
641 Developers with git push ability can use this category, skipping
642 over @code{patch-new}.
645 Patch-needs_work: a developer has some concerns about the patch.
646 This does not necessarily mean that the patch must be changed; in
647 some cases, the developer's concerns can be resolved simply by
648 discussion the situation or providing notation examples.
650 If the patch is updated, the category should be changed to
651 @code{patch-new} (for normal contributors) or @code{patch-review}
652 (for developers who are very confident about their patch).
655 Patch-countdown: final call for any patch problems
658 Patch-push: patch has passed the countdown and should be pushed.
661 Patch-abandoned: the author has not responded to review comments
666 @subheading Other items (optional)
673 Regression: it used to work intentionally in the current
674 stable release or the previous stable release. If the earlier
675 output was accidental (i.e. we didn't try to stop a collision,
676 but it just so happened that two grobs didn't collide), then
677 breaking it does not count as a regression.
679 To help decide whether the change is a regression, please adopt
680 the following process:
685 Are you certain the change is OK? If so, do nothing.
688 Are you certain that the change is bad? Add it to the tracker
692 If you're not certain either way, add it to the tracker as a
693 regression but be aware that it may be recategorised or marked
698 In particular, anything that breaks a regression test is a
702 Frog: the fix is believed to be suitable for a new contributor
703 (does not require a great deal of knowledge about LilyPond). The
704 issue should also have an estimated time in a comment.
707 Bounty: somebody is willing to pay for the fix. Only add this tag
708 if somebody has offered an exact figure in US dollars or euros.
711 Warning: graphical output is fine, but lilypond prints a
712 false/misleading warning message. Alternately, a warning should
713 be printed (such as a bar line error), but was not. Also applies
714 to warnings when compiling the source code or generating
718 Security: security risk.
721 Performance: performance issue.
725 If you particularly want to add a label not in the list, go
726 ahead, but this is not recommended, except when an issue is marked
727 as fixed. In this case it should be labeled Fixed_mm_MM_ss,
728 where mm is major version, MM minor version and ss current
732 @node Adding issues to the tracker
733 @section Adding issues to the tracker
735 @warning{This should only be done by the Bug Squad or experienced
736 developers. Normal users should not do this; instead, they should
737 follow the guidelines for @rweb{Bug reports}.}
739 In order to assign labels to issues, Bug Squad members should log
740 in to their google account before adding an item.
745 Check if the issue falls into any previous category given on the
746 relevant checklists in @ref{Bug Squad checklists}. If in doubt,
747 add a new issue for a report. We would prefer to have some
748 incorrectly-added issues rather than lose information that should
752 Add the issue and classify it according to the guidelines in
753 @ref{Issue classification}. In particular, the item should have
754 @code{Status} and @code{Type-} labels.
756 Include output with the first applicable method:
761 If the issue has a notation example which fits in one system,
762 generate a small @file{bug.preview.png} file with:
765 lilypond -dpreview bug.ly
769 If the issue has an example which requires more than one system
770 (i.e. a spacing bug), generate a @file{bug.png} file with:
773 lilypond --png bug.ly
777 If the issue requires one or two pages of output, then generate a
778 @file{bug.png} file with the normal:
781 lilypond --png bug.ly
785 Images created as @file{bug.png} may be trimmed to a minimum size
786 by using the @code{trimtagline.sh} script, which can be found at
789 @uref{https://raw.github.com/gperciva/lilypond-extra/master/bug-squad/trimtagline.sh}
793 trimtagline.sh bug.ly
797 If the issue cannot be shown with less than three pages, then
798 generate a @file{bug.pdf} file with:
801 lilypond --pdf bug.ly
804 Note that this is likely to be extremely rare; most bugs should
805 fit into the first two categories above.
811 After adding the issue, please send a response email to the same
812 group(s) that the initial patch was sent to. If the initial email
813 was sent to multiple mailing lists (such as both @code{user} and
814 @code{bugs}), then reply to all those mailing lists as well. The
815 email should contain a link to the issue you just added.
822 @section Patch handling
824 @warning{This is not a Bug Squad responsibility; we have a
825 separate person handling this task.}
827 For contributors/developers: follow the steps in
828 @ref{Commits and patches}, and @ref{Pushing to staging}.
831 For people doing maintenance tasks: git-cl is adding issues, James
832 is testing them, Colin is selecting them for countdowns, and
833 Patchy is merging from staging to master. In the coming weeks,
834 these tasks will be more and more automated.
837 @subheading Patch cycle
842 Patches get added to the tracker and to Rietveld by the @qq{git-cl} tool, with
843 a status of @qq{patch-new}.
846 The automated tester, Patchy, verifies that the patch can be applied
847 to current master. By default, it checks that the patch allows @code{make}
848 and @code{make test} to complete successfully. It can also be configured to
849 check that @code{make doc} is successful. If it passes, Patchy changes the
850 status to @qq{patch-review} and emails the developer list. If the patch
851 fails, Patchy sets it to @qq{patch-needs_work} and notifies the developer list.
854 The Patch Meister reviews the tracker periodically, to list patches
855 which have been on review for at least 24 hours. The list is found at
858 @uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch%20patch=review&sort=modified+patch&colspec=ID%20Type%20Status%20Priority%20Owner%20Patch%20Summary%20Modified}
862 For each patch, the Handler reviews any discussion on the tracker
863 and on Rietveld, to determine whether the patch can go forward. If
864 there is any indication that a developer thinks the patch is not
865 ready, the Handler marks it @qq{patch-needs_work} and makes a comment
866 regarding the reason, referring to the Rietveld item if needed.
869 Patches with explicit approval, or at least no negative comment, can
870 be updated to @qq{patch-countdown}. When saving the tracker item,
871 clear the @qq{send email} box to prevent sending notification for
875 The Patch Meister sends an email to the developer list, with a fixed
876 subject line, to enable filtering by email clients:
879 PATCH: Countdown to 20130113
882 The text of the email sets the deadline for this countdown batch. At
883 present, batches are done on Tuesday, Thursday and Sunday evenings.
885 To create the countdown announcement, use the
886 @code{make-countdown-announcement.sh} script, which takes the
887 deadline date, and optionally your name. Follow the instructions
892 scripts/auxiliar/make-countdown-announcement.sh "Jan 1, 2001" James
895 The script produces an announcement that is easily readable in all
896 email clients. Also, whenever a new contributor submits a patch,
897 you will be prompted to add the new username and author name to
898 the script itself, and then commit those changes to the main git
903 On the scheduled countdown day, the Patch Meister reviews the
904 previous list of patches on countdown, with the same procedure and
905 criteria as before. Patches with no controversy can be set to
906 @qq{patch-push} with a courtesy message added to the comment block.
909 Roughly at six month intervals, the Patch Meister can list the
910 patches which have been set to @qq{patch-needs-work} and send the
911 results to the developer list for review. In most cases, these
912 patches should be marked @qq{patch-abandoned} but this should come
913 from the developer if possible.
916 As in most organisations of unpaid volunteers, fixed procedures are
917 useful in as much as they get the job done. In our community, there
918 is room for senior developers to bypass normal patch handling flows,
919 particularly now that the testing of patches is largely automated.
920 Similarly, the minimum age of 24 hours can reasonably be waived if
921 the patch is minor and from an experienced developer.
927 There is a single Patch Meister, and a number of Patch Helpers
928 (rename this?). The list of known patches awaiting review is:
931 @uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch&sort=patch}
935 @subheading Helpers: adding patches
937 The primary duty is to add patches to the google tracker; we have
938 a bad track record of losing patches in email. Patches generally
939 come to the @code{lilypond-devel} mailing list, but are sometimes
940 sent to @code{bug-lilypond}, @code{lilypond-users}, or
941 @code{frogs} mailing list instead.
945 Unless a patch is clearly in response to an existing issue, add a
946 new issue with the @code{Patch-new} label and a link to the patch
947 (either on the mailing list archives or the codereview url).
949 Issue numbers are cheap; losing developers because they got fed up
950 with us losing their hard work is expensive.
953 @c if we enter patches immediately, I don't think this is relevant.
956 Before adding a patch-reminder issue, do a quick check to see if
957 it was pushed without sending any email. This can be checked for
958 searching for relevant terms (from the patch subject or commit
959 message) on the webgit page:
962 @uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git}
968 If the patch is clearly in response to an existing issue, then
969 update that issue with the @code{Patch-new} label and a link to
970 the patch (either on the mailing list archives or the codereview
974 After adding the issue, please send a response email to the same
975 group(s) that the initial patch was sent to.
977 If the initial email was sent to multiple mailing lists (such as
978 both @code{bugs} and @code{devel}), then reply to all those
979 mailing lists as well. The email should contain a link to the
980 issue you just added.
984 @subheading Helpers: @code{Patch-review} label
986 The secondary duty is to do make sure that every issue in the
987 tracker with a @code{Patch-review} label has passed these
992 Applies automatically to git master.
994 It's ok to have offsets, but not conflicts.
997 Regtest comparison looks ok; no unexpected changes.
1000 Descriptive subject line.
1002 Avoid subjects like @qq{fixes 123}; instead write @qq{Doc: discuss
1003 stacking-dir for BassFigureAlignment (fix 123)}.
1006 Compiles docs from scratch. Only check this if you have reason to
1007 suspect it might not work.
1012 Check code indentation and style. This should be easier post-GOP
1013 when we have a better-defined code style.
1018 @subheading Patch Meister
1020 The Patch Meister will:
1025 send @qq{countdown} emails to
1026 @code{lilypond-devel} when patches appear to be ready.
1029 send general requests to review patches, or even nasty requests to
1033 downgrade patches from @code{Patch-review} to
1034 @code{Patch-needs_work} as appropriate.
1037 downgrade patches from @code{Patch-needs_work} to
1038 @code{Patch-abandoned} if no actions have been taken in four
1046 @node Summary of project status
1047 @section Summary of project status
1049 @subsubheading Project overview
1051 Grid view provides the best overview:
1054 @uref{http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids}
1057 @subsubheading Hindering development
1059 These issues stop or slow development work:
1062 @uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Maintainability}
1065 @subsubheading Easy tasks
1067 Issues tagged with @code{Frog} indicates a task suitable for a
1068 relatively new contributor. The time given is a quick
1069 (inaccurate) estimate of the time required for somebody who is
1070 familiar with material in this manual, but does not know anything
1071 else about LilyPond development.
1074 @uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Frog}
1077 @subsubheading Patches to review
1079 Patches which have no @qq{obvious} problems:
1082 @uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch-review}