See the Wishes page for what this is all about.
answers-attachments
*** Oleg Koptev <koptev.oleg {_AT_} gmail.com>
1) ability to attach files in Answers section.
answers-comment-without-changing-state
*** Steve McInerney <steve.mcinerney {_AT_} canonical.com>
2. be able to comment to an answers without the status changing to
either answered or more-information
answers-localization
*** Nasir Khan Saikat <nasir8891 {_AT_} gmail.com>
3. the answering system should make more helpful for the non English speakers .
like it could suggest a person of Bangladesh to ask the question in Bengali
language and similarly for the people of the other countries too.
api-batching
*** Jamu Kakar <jkakar {_AT_} kakar.ca>
2. Batch operations in the Launchpad API
I enjoy using the API, it's very simple and straight-forward, and
I've been able to automate a number of boring processes with it.
For things I do infrequently the cost of making an HTTP request
for each object I want to work with isn't a big deal: I can start
my scripts and let them run for as long as necessary. But, there
are things I'd like to do frequently that are currently too slow.
For example, getting a list of bugs in project X with tag
'review' and printing them in my terminal. A quick test here
shows that it takes 12-15s to get bug and bug task objects for 4
bugs and display them. I want to do this operation 20 times a
day and for that it needs to be faster, at least as fast as
loading the same view in my web browser. Making it possible to
retrieve many objects at once would help.
api-doap
*** Jelmer Vernooij <jelmer {_AT_} samba.org>
1) Registry: Better integration with the rest of the world (DOAP
export/import, ability to parse new releases submitted to
freshmeat/sourceforge, etc)
*** Tim McNamara <paperless {_AT_} timmcnamara.co.nz>
3) Enhanced browsing for new projects - possibly ala Sourceforge - in a
categorical directory
api-event-stream
*** Gavin Panella <gavin.panella {_AT_} canonical.com>
3. Event stream, perhaps pushed out via a MQ. The API is fantastic,
but something like this would open up even more integration
possibilities.
blogs
*** Magnun Leno <magnun.leno {_AT_} gmail.com>
3. Some kind of blog where we can post things we're working on in order to
inform, ask for suggestions, make pools or simply have/give some feedback.
blueprints-comments-etc
*** Przemek Kulczycki <przemekkulczycki {_AT_} gmail.com>
3) Comments for blueprints or some integration with Ubuntu
Brainstorm/IdeaTorrent to allow ordinary users to comment on
blueprints in an easy way. Currently you have to either edit the
linked wiki page (if any page is linked) or edit the whiteboard which
is prone to whole page/whiteboard deletions by newbies not familiar
with these tools. Also whiteboard should be like a wiki page, ie. with
history/previous versions available.
[ Editor's note: Andrea Corbellini working on this, see
https://bugs.edge.launchpad.net/blueprint/+bug/49698 ]
*** Micah Gersten <launchpad {_AT_} micahscomputing.com>
2. Improved Blueprints (Comments, Revision History)
branch-to-email-linkage
*** Vincent Ladeuil <v.ladeuil+lp {_AT_} free.fr>
3) Better links between mailing lists and code branches (ask
Barry Warsaw about that one if you don't understand what I
mean :), roughly many discussions leads to patches and code
but there is no way to come back to discussions from the
annotated code.
bugs-apport-dup-detection
*** John McCabe-Dansted <gmatht {_AT_} gmail.com>
1) Make it easy to tell if a bug with the exact same summary has been
proposed. If apport creates with summary "Title signal 5 in foo_bar",
tell me whether a bug with the exact same summary has been reported. I
am guessing that if the summaries differ then the bug is either
different or that at least exhibits different symptoms which may
assist in debugging.
Ideally this would also be integrated into apport so that I just get a
message saying "this is a known bug" before having to upload several
MB of test data, but just increasing the size of the Summary text area
in launchpad so that I can see the whole apport generated summary
would be a start.
bugs-by-package-version
*** Andreas Moog <andreas-launchpad {_AT_} warperbbs.de>
1. Be able to specify (and filter on) bugs found in a specific package
version, like the debian BTS has.
bugs-comment-tagging
*** Maris Fogels <maris.fogels {_AT_} canonical.com>
• I wish it was easier to find a specific Ubuntu bug that affects
me, and to find out what I should do about it. Which of the many
duplicate bugs has a workaround buried in the comment thread?
bugs-dependency
*** Robert Collins <robert.collins {_AT_} canonical.com>
Thirdly, I'd love bugs to be more dynamic. This is a bit meta, but its
annoying that they don't have dependencies [I know that bugs aren't
blueprints - I don't want to turn bugs into blueprints, just to be able
to say 'bug X is blocked on bug Y'. This happens *even when the problem
is conceptually trivial*, and being unable to represent it in the bug
database makes working with those situations tricky.
bugs-foreign-tracking-improvements
*** Julien Lavergne <julien.lavergne {_AT_} gmail.com>
2. Make status from other bug trackers working better (especially with
the Debian BTS)
*** Graham Binns <graham {_AT_} canonical.com>
2. Better syncing with remote bug trackers.
bugs-hug-day-tag
*** Franczen Attila <franczena {_AT_} gmail.com>
- This is a minor thing, but: I would like to see hug-day bugs under
ubuntu-bugs, under a tag, or something.
bugs-importance-continuum
*** Robert Collins <robert.collins {_AT_} canonical.com>
Thirdly its a shame that there are only 5 buckets of importance for bugs
(its a spectrum really - give me any two bugs in a single project and I
can usually say 'X first', but the bug tracker can't do that for *other
people*.) I think Aaron Bentley talked about this first, and I think it
would totally rock.
(Yes, I know there are two Thirdly's there. Can't blame me for trying).
bugs-multiple-attachments
*** Franczen Attila <franczena {_AT_} gmail.com>
- I would like to add multiple attachments to a bug report, or to a
comment. I am sure this is possible, but the how is not under my nose,
and I am lazy to dig after it. So sometimes I just attach only one
attachment, even if I could have attach more info. (Throw a brick at
me, I deserve it)
*** Tuomas Aavikko <taavikko {_AT_} gmail.com>
I would settle for one feature, ability to add more attachments manually to
bugs, rather than one at a time.
bugs-per-user-prioritization
*** Barry Warsaw <barry {_AT_} canonical.com>
3. User defined bug prioritizing. So I have 7 High priority bugs that
I have to fix this cycle and hopefully will have time to do so. My
manager and I have negotiated a priority order in which I'm supposed
to attack these bugs. How do I capture that in Launchpad? Note that
my priority might be different than your priority for the same bugs,
which is great because if you get to bug 123 before I do, you'll take
it.
On the subject of bugs, I gave a talk at our local Python Users Group
on Monday on lazr.restful and argparse. Both talks went well, but
what caught my attention was John Szakmeister's presentation of a cool
Trac plugin. Here's what I wrote to an internal mailing list about
it...
So the idea behind this was that he had a list of milestones along the
right side of the page, and a table of bugs in the main part of the
page. He said that one of the things they do all the time is sit with
the client and re-prioritize bugs. He is able to drag-and-drop bugs
up and down his list to re-prioritize them. It looked a lot like the
way I can drag-and-drop movies in my Netflix queue to reorder them.
That in itself was pretty cool, but then he showed how they can assign
bugs to milestones by dragging them from the main table into the
little milestone boxes on the right side. When he expanded the
milestone, there were the bugs he'd dragged in. It would have been
cooler if the milestone boxes displayed the dragged bugs in real time,
but still it was a pretty cool demo.
I really liked that he was thinking about prioritizing bugs and came
up with a very intuitive way of doing it, as well as a simple
intuitive way of assigning bugs to milestones. Might be something to
think about for bugs.lp.net in the future.
bugs-reporting-customization
*** Michael Terry <michael.terry {_AT_} canonical.com>
3 Bug Progress Quest (a.k.a. not-everyone-uses-apport): there may be
several (say, 4) bits of info my project requests from the user as they
enter a bug. It would be nice if LP had support for providing feedback
that the bug wanted all 4. For example, show 4 entry boxes or 4 upload
fields for the submitter and have a little progress bar on the bug
saying "50% done; you can do it!". Maybe leave the bug as Incomplete
until it's 100%. c.f. Facebook and LinkedIn user profile completion
feedback.
bugs-small-fixes
*** Martin Pool <mbp {_AT_} canonical.com>
1- General workflow-oriented polish on the bugs application: for
example, using my (popularly acclaimed :-) idea of saying "and 43
closed bugs" when your search matches them
<https://bugs.edge.launchpad.net/malone/+bug/277352>, or showing
milestone-targeted bugs in a portlet, or showing the count of affected
users, or not losing your search text when going from a simple to an
advanced search or have a google-like boolean search language, or do
an answers-like "this needs info/here's the info" handoff.
In other words, in Bugs, don't add new stuff, just do small fixes to
make what's already there more pleasant.
bugs-time-based-tracking
*** Jamie Bennett <jamie {_AT_} linuxuk.org>
1. Time based tracking on bugs.
For example:
I click 'Working on this bug' when I start, I click 'Fixed' (or 'not
working on it any more', e.t.c) when I'm not. Bugs then have a time
associated with how much effort they took to fix. This can be used in
combination with an 'estimate' field which would allow correlation
between estimates and actual times. This concept could be expanded a
lot further to allow a more scrum and agile tracking tool.
[ Editor's note: is this already available via APIs? ]
bugs-track-fix-quality
*** Tom Berger <tom.berger {_AT_} canonical.com>
3. Facilities for tracking the quality of bug fixes.
[ Editor's note: Jonathan Lange followed up on-list asking what it
means, see https://lists.launchpad.net/launchpad-users/msg05307.html ]
bugs-triage-simulator
*** Eric Nathan Hickman <eric.nathan.hickman {_AT_} gmail.com>
1)Bug-Triage-Simulator, for providing the information project
developers and leaders want their traigers to know in a
unified way.
https://blueprints.launchpad.net/launchpad/+spec/lanuchpad-bug-simulator
bugs-upstream-forwarding
*** Alan Pope <alan {_AT_} popey.com>
1. Register my upstream bug tracker identities in launchpad to allow
me to hit a "forward this upstream" button.
bugs-versions-affected
*** Micah Gersten <launchpad {_AT_} micahscomputing.com>
1. Versions for bugs (Affected versions [Maybe Multiple], Fixed Version)
bugwatcher-frequency
*** Andreas Moog <andreas-launchpad {_AT_} warperbbs.de>
2. Update bugwatches more frequently. I know that this is most often a
problem with the remote bugtracker but Launchpad could retry more
often.
bzr-branches-independent-of-projects
*** Andreas Moog <andreas-launchpad {_AT_} warperbbs.de>
3. Be able to create bazaar branches not depending on specifying a
project or using +junk. I want to push to lp:~user/project/branch
without the need of creating the project beforehand.
bzr-branches-to-packages
*** Jelmer Vernooij <jelmer {_AT_} samba.org>
2) Ability to build packages by pushing a Bazaar branch
*** James Westby <jw+debian {_AT_} jameswestby.net>
3) Source packages from bzr branches.
We have a proposed plan for this, let's make it happen, it will be great.
Relatedly, while I don't use it I'm a fan of the bzr/translations integration,
and think more of this "loop closing" would be very beneficial. For instance,
the bug life-cycle being driven by a branch where one is attached would be
great. Launchpad deals with all these areas of project management currently,
but it doesn't make the most of opportunities to capitalise on the integration.
bzr-foreign-import-improvements
*** Dmitrijs Ledkovs <dmitrij.ledkov {_AT_} gmail.com>
3. Use bzr-svn for svn imports.
bzr-stats
*** "Coke" on IRC, channeled via Martin Pool <mbp {_AT_} canonical.com>
2. Download/branch counts for bzr branches
bzr-writes-via-web
*** Jacob Peddicord <jpeddicord {_AT_} ubuntu.com>
2) Ability to edit and commit to any Bazaar branch from the web
interface. Useful for when working away from home or making quick
changes. I should be able to open a file in Launchpad, change a line,
hit save, commit, and be done with it.
calendar
*** Jamie Bennett <jamie {_AT_} linuxuk.org>
3. Integrated calendar and schedule support.
code-review-improvements
*** Vincent Ladeuil <v.ladeuil+lp {_AT_} free.fr>
1) A better code review workflow (see all bugs related to
lp:mad), roughly the diffs are often out of sync with the
submitter point of view and resubmitting breaks the discussion
into several threads, plus the generated mails don't play well
with mailing lists (ask Aaron about that :)
*** Martin Pool <mbp {_AT_} canonical.com>
2- Develop the code review feature more: always supply a diff, make it
easier to comment on the diff, and make the fact that the code review
is happening visible in other places (like bugs). This is moving
really well recently so I'm basically saying, don't let up the
pressure.
*** James Westby <jw+debian {_AT_} jameswestby.net>
2) Sexy code review.
I realise that there is work going on in this area, but it is still my
main wish for 4.0, and one that I can reasonably hope to see implemented.
Code review is one of the most important activities that we do, we should
do lots and lots of it, and our tools should allow us to focus on reviewing
the code and help us to get the highest quality possible. It is also one
of the things that a code hosting site should excel at.
I find the current system to vary between usable and good, and I don't think
that's enough. I think Launchpad's code review system and workflow should
knock your socks off, it should cause people's jaws to drop the first time
they see it, and cause them to flock to Launchpad; we don't have that yet.
I realise it is tough, but I think this should be the major focus of the
Launchpad Code team for the next cycle, with help from the other teams to
integrate it well (along with making Code work well for Ubuntu ;-)
comment-admin-ui
*** Steve McInerney <steve.mcinerney {_AT_} canonical.com>
From the admin perspective and thus being able to better support
users :-)
1. delete/disable/hide THIS comment in the UI - just one measly little
admin-visible-only button - pls pls pls pls?
debian-ppas
*** Julien Lavergne <julien.lavergne {_AT_} gmail.com>
1. Debian packages in PPA (see bug 188564)
*** Andrew SB <a.starr.b {_AT_} gmail.com>
3. Debian PPAs - https://bugs.launchpad.net/soyuz/+bug/188564
*** John McCabe-Dansted <gmatht {_AT_} gmail.com>
2) I agree that Debian packages in PPAs would be nice.
delay-reduction
*** Vincent Ladeuil <v.ladeuil+lp {_AT_} free.fr>
2) Better ways to force some automatic actions (imports or
mirroring comes to mind) but as a principle, it's quite
irritating to see launchpad say: 'I will do it in 4 hours'
when you need it *now* :)
distro-as-upstream
*** Matthew East <mdke {_AT_} ubuntu.com>
I only have one. It's to fix https://bugs.launchpad.net/bugs/76416
(Handle a distribution being its own upstream for a package).
doc-hosting
*** Robert Collins <robert.collins {_AT_} canonical.com>
Secondly, I would _love_ the ability to have docs of some sort visible
in my projects. I don't particularly care about vhosts or anything like
that. Markdown, or Sphinx. Or ReST - all good. There are cross site
attack implications here, so its likely we'd *need* vhosts, but thats a
different discussion. Currently there is no where that I can go to put
online browsable documentation such as HOWTO's and intros. Heck, even a
single page pulled from trunk, inline on the project homepage would be
wonderful. Equally a wiki would be great, it would allow this use case
and more : but a wiki is not intrinsically valuable in this way.
https://edge.launchpad.net/subunit is a good page to look at to see how
bland 'here is my <foo>' looks at the moment.
*** Dmitrijs Ledkovs <dmitrij.ledkov {_AT_} gmail.com>
2 generated documentation hosting per series/milestone.
*** nazo <lovesyao {_AT_} gmail.com>
3) API references for distribution's libraries (use *-doc packages?)
do-less-be-smaller-be-smoother
*** Matthew Paul Thomas <mpt {_AT_} canonical.com>
My three wishes: Do less, do it smaller, do it smoother.
By "less" I mean getting rid of things like blueprint feedback requests,
which have never worked[1][2]; the Fix Released bug status, which has
never worked[3]; the Incomplete bug status, which hasn't worked for a
year or so; CVE pages[4], which as far as I can tell, have never been
used by their target audience[5]; poll option "names", which are
useless[6]; and the unused project fields -- such as Freshmeat URL --
that make projects a chore to register[7]. I also mean merging things
that cause aggravation or confusion by their separation: for example,
make bug reports and blueprints interchangable variants of the the same
thing[8], make milestones and releases interchangable variants of the
same thing[9], make code-browsing pages use exactly the same navigation
as the rest of Launchpad, and make launchpadblog and Planet Launchpad
the same Web site.
By "smaller" I mean more power in the same, or less, amount of
interface.[10] For example, it should be possible to do advanced bug
searches without navigating a huge advanced search page.[11] It should
be possible to set up a team poll without having to enter each option on
a separate page load. It should be possible to set up translations, in
the project you've just registered, without having to spelunk through
half a dozen pages.[12][13] And bug tags should be easy and powerful
enough that Launchpad developers themselves don't need to use fake
projects to categorize their bug reports. Part of this is just using XHR
more -- but most of it is thinking about, user testing of, and designing
for, user goals rather than pages in isolation.
And by "smoother" I mean designing and implementing not just changes,
but the process for announcing and teaching the changes. Introducing a
small feature? For each user, remember whether they've dismissed the
highlighted help box that points to the feature and links to more
detailed help. Introducing a big feature? Publish a screencast of it
a week ahead of time, and again use a dismissable help box on
appropriate pages to link to the screencast. Finally lighting up a
long-disabled tab (such as the Code tab for source packages)? For a
month afterward, stick a "New!" starburst on the tab for the appropriate
pages. Moving something to another position on the same page? For
two weeks afterward, put an explanation in the old position with a link
that scrolls to and highlights the new position. Launchpad is a Web
site: people don't have the luxury of delaying upgrading to the next
major version until they're ready. So Launchpad shouldn't have major
versions like "3.0" or "4.0"[14]; instead, there should be constant
small improvements, each with its own guides and signposts.
Thanks to Jono Lange for a conversation that helped brainstorm and
clarify some of these ideas.
[1] http://launchpad.net/bugs/3522
[2] http://launchpad.net/bugs/125394
[3] http://launchpad.net/bugs/163694
[4] http://launchpad.net/ubuntu/+cve
[5] They use <http://launchpad.net/ubuntu-cve-tracker> instead.
[6] http://launchpad.net/bugs/179441
[7] https://dev.launchpad.net/RegistrySimplifications
[8] https://dev.launchpad.net/IssueTracker
[9] http://launchpad.net/bugs/174468
[10] http://www.uie.com/articles/experiencedesign/
[11] http://launchpad.net/bugs/5594
[12] http://launchpad.net/bugs/60939
[13] http://launchpad.net/bugs/264109
[14] http://www.uie.com/articles/death_of_relaunch/
downloads-improvements
*** Magnun Leno <magnun.leno {_AT_} gmail.com>
2. Improve download area, showing simple things like the date that a file was
added and add the possibility to edit file details...
faster
*** Franczen Attila <franczena {_AT_} gmail.com>
- faster load of the page: it really annoys me, that it is this slow.
*** Andrew SB <a.starr.b {_AT_} gmail.com>
1. Performance. It seems like there has been some progress here, but
since you all rock I know you can do even better. ;-) Three random bug
pages:
<!-- at least 84 queries issued in 3.12 seconds -->
<!-- Launchpad 2.2.6 (r8327) -->
<!-- at least 82 queries issued in 4.32 seconds -->
<!-- Launchpad 2.2.6 (r8327) -->
<!-- at least 71 queries issued in 4.16 seconds -->
<!-- Launchpad 2.2.6 (r8327) -->
*** Michael Hudson <michael.hudson {_AT_} canonical.com>
2) Better performance.
*** Maris Fogels <maris.fogels {_AT_} canonical.com>
• I wish the site was much, much faster.
git
*** Julien Lavergne <julien.lavergne {_AT_} gmail.com>
3. Git native support in code hosting
(btw, 1 and 2 have very higher priority in my wishes than 3 :))
*** Wolfgang Silbermayr <wolfgang.silbermayr {_AT_} gmail.com>
1) Git support for code
*** Michael Hofmann <mh21 {_AT_} piware.de>
1) native git hosting
2) [...]
3) native git hosting again :-)
*** Jan-Marek Glogowski <glogow {_AT_} fbihome.de>
3. Code hosting with native Git support
hardware-database
*** Alan Pope <alan {_AT_} popey.com>
3. Hardware registration database to allow users to easily send data
about their system to lp for answers. A kind of apport for answers.
[Editor's note: under way, see Kiko Reis's response: "Surprisingly,
we have half of this with hwtest; the only bit missing is updating
the UI and perhaps allowing hw profiles to be linked to answers.
Patches welcome (you knew it was coming, but man, it's been years
I've been waiting to say it!)" ]
localized-web-ui
*** Dmitry Agafonov <dmitry {_AT_} agafonov.pp.ru>
1, 2 and 3 - Localized web ui.
Is LP translatable at all?
*** SkyMan <skymanphp {_AT_} gmail.com>
1. Multilingual Lauchpad UI (Translations at the first)
*** Jan-Marek Glogowski <glogow {_AT_} fbihome.de>
1. i18n of the UI
*** Legendario <kemel.zaidan {_AT_} ubuntu-sp.org>
4. Do I have the time for a fourth one? Because I think these is my major
wishe: I would really, really like a way to translate Launchpad itself,
because for LoCo teams, there are some tasks that are still difficult for
newcomers such as the signing of the CoC and some other things. Translation
teams could be in charge of that and use Rosetta for the task. People who
doesn't speak English can also support Ubuntu on other fields such as LoCo
teams.
*** Nasir Khan Saikat <nasir8891 {_AT_} gmail.com>
1. a option to use launchpad in users native language.
log-in-by-username
*** Jacob Peddicord <jpeddicord {_AT_} ubuntu.com>
Also, because it's minor:
4) Ability to login using your ~username instead of email address.
This annoys me to no end.
*** David McNally <david3333333 {_AT_} gmail.com>
2) login with username, not email
mailing-list-improvements
*** Przemek Kulczycki <przemekkulczycki {_AT_} gmail.com>
2) Better mailing list subscription management (subscribe/unsubscribe
to many lists at once) and better mailing list archives (searchable,
show whole threads like google groups/forums)
*** Andrea Corbellini <andrea.corbellini {_AT_} beeseek.org>
1. Better mailing list subscription/management options, especially for
new users. For example: someone should be able to subscribe to a
mailing list also without being member of that team; unregistered and
logged out users should be able to know how to subscribe from the
team page.
markup
*** Michael Terry <michael.terry {_AT_} canonical.com>
2 Allow simple markup in project descriptions (links, lists)
merge-proposal-diff-updates
*** Mirco Müller <mirco.mueller {_AT_} canonical.com>
Really cool would be the ability of LP to automatically update the
displayed diff in a Merge-Proposal, if one pushed a new commit to the
merge-proposed branch.
Right now it only displays the initial diff against the original
branch. All following commits to that new branch are only listed as
separate revisions making reviewing harder for people who did not follow
the change history and stepped in later for code-review.
It would make my life easier when wearing my code-review hat.
milestone-reassignment-ui
*** Julian Edwards <julian.edwards {_AT_} canonical.com>
2. Milestone re-assignment directly from milestone or personal lists (it
takes *way* too long to do this job right now because I have to visit each bug
page separately)
morphing-dialogs
*** David McNally <david3333333 {_AT_} gmail.com>
3) better interface... something with little animations, perhaps? (something
like in the example at http://www.markshuttleworth.com/archives/239 )
news-feeds
*** Tim McNamara <paperless {_AT_} timmcnamara.co.nz>
2) Either (or both) - ability for projects to have news feeds from a project
site or upload blog/news posts
news-global-like-freshmeat
*** Steve McInerney <steve.mcinerney {_AT_} canonical.com>
From a personal project management perspective:
3. a centralised "what's new"/Announcements for ALL projects. a-la
freshmeat.
There are two major missing features, imho, in running a project on LP:
a. generic website/page information - eg wiki as a solution.
b. a central announcer
Every announcement I've done on freshmeat brings in new folks who've
never heard of the projects or what they do. LP helps hugely with the
day-to-day running of a project, but plays a very minor role in the
marketing - and thus long term growth - of a project.
Rephrased: I grow the project via freshmeat, I run it via launchpad.
notification-customization
*** Jacob Peddicord <jpeddicord {_AT_} ubuntu.com>
3) More email notification customization. Currently LP emails you
about everything *it* thinks is important. There are a few situations
where I'd like to follow something but disable email notifications for
it. RSS would be an alternative to following bugs/answers/etc.
*** Eric Nathan Hickman <eric.nathan.hickman {_AT_} gmail.com>
3)Do something about the launchpad email noise maby, turn
off notifications for duplicate bugs check box ; )
*** Graham Binns <graham {_AT_} canonical.com>
3. Better management of my mail notifications so that I don't feel
like I'm trying to sip from a firehose.
*** Christopher Armstrong <radix {_AT_} twistedmatrix.com>
2. The ability to disable mail notifications that are directed to me
through a specified team. I'm in some teams that were made part of
other teams and it bugs me that I receive those indirect team emails.
I'm also in some teams for the access that membership provides but
don't want to receive email from them.
*** Alex Launi <alex.launi {_AT_} gmail.com>
3) Configurable email preferences to cut down some of the noise, and make the
noise more easily automatically sortable
openid-login
*** Wolfgang Silbermayr <wolfgang.silbermayr {_AT_} gmail.com>
3) Allow OpenID login
paste
*** Gavin Panella <gavin.panella {_AT_} canonical.com>
2. Paste-bin, authenticated, with the ability to link/attach pastes to
comments in bugs, merge-proposals, answers, etc.
*** Andrea Corbellini <andrea.corbellini {_AT_} beeseek.org>
3. Pastebin (just a tiny UI to the librarian would be OK for me).
personal-dashboard
*** Andrew SB <a.starr.b {_AT_} gmail.com>
2. I've always thought that it would be nice if your profile page
(don't know what your terminology is, but I mean e.g
https://launchpad.net/~andrewsomething) was more of a dash-board when
logged in. The current view would be your public face, but when logged
in it would present you with information directly relevant to you:
most recent comments on subscribed bug, recent commits, display
assigned bugs in a todo list fashion, ect... I know where I live and
what my email address / irc nick / jabber nick / OpenPGP key are. I
know what languages I speak and what teams I belong to. Currently the
profile page isn't useful at all for its owner.
*** Alan Pope <alan {_AT_} popey.com>
2. http://www.ubuntustats.com/ type thing but personalised for me,
based on my projects, teams, bugs etc
*** Alex Launi <alex.launi {_AT_} gmail.com>
2) A personal homepage/dashboard page that would have updates since last login
about bug activity, pending merge requests, all the other things related to me
and the projects I'm involved with on launchpad
*** Julian Edwards <julian.edwards {_AT_} canonical.com>
1. Arbitrary lists of bugs (akin to milestones, but personal lists)
*** Michael Hudson <michael.hudson {_AT_} canonical.com>
3) More task management/personal dashboard stuff.
*** Ali Sabil <ali.sabil {_AT_} gmail.com>
2) A dashboard/control-center for the logged in user showing
information relevant to him/her like recent commits, bug activities
*** James Westby <jw+debian {_AT_} jameswestby.net>
1) A personal page that helps me organise my work; where's the page that
shows me all the code review that I have been asked to do across LP?
Logging in and going to a page that is tailored to my work would save
me having to poll multiple pages in LP and allow me to do things that
I can't currently do.
Being able to see outstanding code reviews that I have to do, reviews
I requested that need fixing, bugs assigned to me or where I have
been asked a question, bugs that have had activity since I last looked
or requested information, new bugs that need triage in projects that
I work on, new branches pushed to projects that I own, translations
that need approving, questions that I can probably answer, open bugs
that are targeted to an approaching milestone would be great. Then
use some magic algorithm to sort it all, and allow me to filter and
turn up and down the information I get about particular projects or
areas of LP would make it perfect.
pervasive-restructure-text-support
*** Barry Warsaw <barry {_AT_} canonical.com>
1. Pervasive reStructuredText support. This means that I can enter
reST into any textbox and it will be properly formatted, including
description fields, whiteboards, blueprints, bug comments, merge
proposal reviews, etc. It also leads naturally to supporting reST
formatted documentation, wikis and blogs.
*** Jan-Marek Glogowski <glogow {_AT_} fbihome.de>
[ Editor's note: listing this here as well as in wiki, because it's
so similar to Barry's suggestion above. ]
2. Integrated wiki (and wiki syntax for most textbox fields
like description, bugtracker, ...)
pony
*** James Westby <jw+debian {_AT_} jameswestby.net>
4) A pony.
Oh, go on.
ppas-show-official
*** John McCabe-Dansted <gmatht {_AT_} gmail.com>
3) Official PPAs directly linked to package names. so e.g. if I want
to upgrade to the latest version of abiword, I can go to
ppa_official.launchpad/abiword
and choose from various possible versions maybe "latest_2.4.x",
"latest_stable" and "latest_development" etc. In principle this could
break the system, but
- we could have user reviews saying whether the new version worked
for them, if they had difficulty downgrading etc.
- We could limit these PPAs to contain changes from upstream only
(or changes approved by Ubuntu Developers) and so we would at least
know that these wouldn't add malware to the system.
This feature could be linked into the Ubuntu Software Store.
project-management-tools
*** Micah Gersten <launchpad {_AT_} micahscomputing.com>
3. Better Project Management -- Timelines, Tasks, Roadmaps, Calendar
*** Julian Edwards <julian.edwards {_AT_} canonical.com>
3. Timelines, Gantt charts and resource management
questionnaire
*** nazo <lovesyao {_AT_} gmail.com>
1) Questionnaire feature like Google Docs Forms
real-time-commenting-editing
*** Tom Berger <tom.berger {_AT_} canonical.com>
1. Real-time commenting / editing (think Wave).
realtime-notification-like-xmpp
*** Christopher Armstrong <radix {_AT_} twistedmatrix.com>
3. An IRC bot that mentions tip changes on launchpad-hosted branches. :-)
*** Xavier Maillard <xma {_AT_} gnu.org>
1. XMPP notifications and interactions with most part of a
project (bug comment, adding new bug repots, ...)
release-automation
*** Martin Pool <mbp {_AT_} canonical.com>
3- More work on the milestone/release/announcement feature: making a
release should automatically send mail and go into a feed; we can help
upstream developers here a lot by doing this. Make the project as it
appears in Launchpad reflect what's important to the project: releases
and announcements are important.
search-allow-wildcard
*** Oleg Koptev <koptev.oleg {_AT_} gmail.com>
2) wildcards in search field
searching-ranking
*** Tom Berger <tom.berger {_AT_} canonical.com>
2. Sophisticated searching and ranking of bugs and other Launchpad
objects based on their metadata.
[ Editor's note: Jonathan Lange followed up on-list asking what it
means, see https://lists.launchpad.net/launchpad-users/msg05307.html ]
social-ui
*** Ali Sabil <ali.sabil {_AT_} gmail.com>
1) A mini-launchpad website that links into launchpad.net (uses the
same backend) but exposes a simplified/social interface like github or
bitbucket, since I get the feeling that launchpad is just too powerful
for most people.
[ Editor's note: See Sidnei da Silva's followup at
https://lists.launchpad.net/launchpad-users/msg05347.html. He
says: "I like this idea. I suspect if enough of the API is
exported through launchpadlib, someone could put together a demo
of this running on Google App Engine in a matter of days." ]
*** Robert Collins <robert.collins {_AT_} canonical.com>
I _really_ want the ability to say 'these are the mailing lists' and
'this is the wiki' for my projects, without having that just hyperlinked
in the description. Its real metadata, representable in DOAP, even if
launchpad can only host some of this. There is a bug of mine open thats
broadly about this, but seems to have been suborned into the new links
to the bug tracker etc.
https://bugs.edge.launchpad.net/launchpad-registry/+bug/179561
team-affiliation
*** Barry Warsaw <barry {_AT_} canonical.com>
2. Project/team affiliations. As a user interested in a project, I
want to be able to go to a project's index page and immediately see
"team X is the user community and has a mailing list" "team Y is the
developer community" "team Z has commit rights", etc. As a project
manager, I want to be able to make and manage these explicit
connections between projects and teams in one place.
translations-automoderation
*** SkyMan <skymanphp {_AT_} gmail.com>
3. Automoderation of Launchpad Translation Team's Users.
a) if the user's translation strings was a lot of time corrected by others it
brings down his karma;
b) negative karma; if it less than X, this user have to be autobanned [with
team admin notification]
translations-autosuggestion
*** SkyMan <skymanphp {_AT_} gmail.com>
2. Make available suggestion strings to be proposed from dictionary
(translation tool, third party maybe). It's like
premoderated autotranslation.
translations-categorization
*** Alexey Balmashnov <a.balmashnov {_AT_} gmail.com>
2. Categories (tags?) to structure translatable entities
It is difficult to focus translators work on particular distribution
or part of distribution. Currently, all translatable packages are in
one huge non-categorized list. If translators team or part of the team
wants to focus work on the particular flavor, extra
organizational/administration is necessary. Yep, there are some highly
weighted items on top of the list, like installers, documentation etc,
but even this part of the list is messy. Clear categorization of the
translatable packages/items by
- flavor: ubuntu, kubuntu, ...
- availability: e.g. installed by default vs additionally available
applications in repositories + indication of applications popularity
- activeness of upstream
etc. May greatly improve translation process and quality of the
distribution translation delivered to the end-user, which means better
user experience.
[ Editor's note: see followup from Danilo Segan at
https://lists.launchpad.net/launchpad-users/msg05308.html
and Alexey's response to that. ]
translations-feedback
*** Kenneth Nielsen <k.nielsen81 {_AT_} gmail.com>
1) The possibility to give translators feedback on individual
translation suggestions (both with and without approving the
translation in the same go), feedback which they will automatically be
made aware of e.g. per e-mail.
*** ngmail {_AT_} sapo.pt
1. Better tools for doing translation reviews. Being able to give
translators feedback on individual suggestions
translations-glossary
*** Nasir Khan Saikat <nasir8891 {_AT_} gmail.com>
2. in the online translation there should a option to suggest the glossary.
like it is available in Facebook translation.
*** Diego Donati <diegodonati {_AT_} yahoo.it>
[...]
-The possibility to load personal glossaries or to have a general
Launchpad glossary with all the equivalent terminology.
-A specific dictionary for common code terminology
[...]
[ Editor's note: see translations-misc for this person's full list
(which had more than three wishes), and see original thread for
followups https://lists.launchpad.net/launchpad-users/msg05309.html ]
translations-mentoring
*** ngmail {_AT_} sapo.pt
2. Expanding the mentoring system to translations.
translations-misc
*** Diego Donati <diegodonati {_AT_} yahoo.it>
For the translation section, I would like to it to have the following
things:
-fuzzy matching
-the possibility to upload personal TM's
-a checking utility that checks that the strings being translated work
properly and do not mess up things (if strings do not make sense or
mess up things in that specific programming language or code then
Launchpad should highlight things).
-The possibility to load personal glossaries or to have a general
Launchpad glossary with all the equivalent terminology.
-A specific dictionary for common code terminology
[ Editor's note: see the original thread for followups from Danilo
and Kiko: https://lists.launchpad.net/launchpad-users/msg05309.html ]
translations-more-karma
*** Legendario <kemel.zaidan {_AT_} ubuntu-sp.org>
2. I may also like the translations to worth more karma, cause in my opinion
it doesn't reflect the difficulty of the task, as it is today. But this is
not exactly a tool or feature request. ;-)
translations-preview
*** Alexey Balmashnov <a.balmashnov {_AT_} gmail.com>
3. Preview of translated documentation
Translation process for documentation based on Rosetta
does not take into account, that translations normally should be
reviewed as a whole. When a number of people are translating
particular document paragraph by paragraph, you may see this directly
in final translated document, when you read it as a whole. Number of
issues here. Once one is busy with chunk by chunk translation, the
style considerations for a totality of your work are the last ones you
think of. An even if one wants to check and proof-read final version
of document, he/she should dig into so many technical things (bzr,
xml, xsl, figures etc) to get the overall view on the translated
document with a hand-driven process like: download document from
Rosetta - generate xml/html representation of the document - read.
Further on, upon proof-reading, all changes should be made directly in
the Rosetta with repetition of the download, merge, generate
proof-reading cycle.
[ Editor's note: see followup from Danilo Segan at
https://lists.launchpad.net/launchpad-users/msg05308.html
and Alexey's response to that. ]
translations-qt4-imports
*** Michael Hofmann <mh21 {_AT_} piware.de>
3) ability to import qt4 translation files (.ts)
translations-ui
*** Kenneth Nielsen <k.nielsen81 {_AT_} gmail.com>
3) Personal setting for the number of translation strings viewed per
page, default is annoyingly 10. Yes yes I know I can adjust it with
some adress line magic, but it is not quite the same.
*** Alexey Balmashnov <a.balmashnov {_AT_} gmail.com>
NN. Small bonus... [Colored] Diff-s.
Suggestions and variants of translation are nice, but they
pretty much loose their value, when someone can not recognize in a
blink of an eye the difference between translation variants. Area of
improvement.
[ Editor's note: see followup from Danilo Segan at
https://lists.launchpad.net/launchpad-users/msg05308.html
and Alexey's response to that. ]
translations-upstream-sync
*** Alexey Balmashnov <a.balmashnov {_AT_} gmail.com>
1. Some sort of locking strings/permissions mechanism
There is no automation of the translation propagation to upstream.
Want to cooperate with upstream? Get your hands dirty and do it by
hand. But... There is no indication or whatsoever that strings to be
translated are actually different from upstream, or not at all used in
upstream. If one translates something, he has no clue whether this
string might be already translated elsewhere/upstream, which surely
leads to a duplication of work, difficulties in merging translations
with or from upstream, which finally results in tensions between
translators working on Ubuntu and upstream. One of the possibilities
here might be in clear indication, that strings are unique to Ubuntu
and ability to focus translation work around them, for example, via
locking strings that for sure are coming from active upstream projects
like GNOME.
Another possible use of lock mechanism.
It might be also employed in the translation process, when
reviews are being performed, e.g. upon finishing translation and
review string gets frozen without ability of most translator team
members to change it directly, but only make suggestions. It might be
based on translator quality/experience ranking based on voting system
or somehow else.
*** Legendario <kemel.zaidan {_AT_} ubuntu-sp.org>
3. I would like also a way to automatic sync and merge translations with
upstream teams such as KDE and many others. I am not a developer but I
believe this could be done with an API or something like that. Am I right?
ui-consistency
*** Ali Sabil <ali.sabil {_AT_} gmail.com>
3) Better overall design, currently the different sections of
launchpad look very similar and thus very confusing
ui-navigating-to-code
*** Maris Fogels <maris.fogels {_AT_} canonical.com>
• I wish it was easier to find and work with a project's sourcecode.
I have to surf miles from the project's home-page to browse the code,
or to find the link to the next step in a merge proposal.
web-hosting
*** Dmitrijs Ledkovs <dmitrij.ledkov {_AT_} gmail.com>
1 webhosting
formatted reST docs from bzr branch.
*** Xavier Maillard <xma {_AT_} gnu.org>
2. reST homepage for a project
*** Robert Collins <robert.collins {_AT_} canonical.com>
Secondly, I would _love_ the ability to have docs of some sort visible
in my projects. I don't particularly care about vhosts or anything like
that. Markdown, or Sphinx. Or ReST - all good. There are cross site
attack implications here, so its likely we'd *need* vhosts, but thats a
different discussion. Currently there is no where that I can go to put
online browsable documentation such as HOWTO's and intros. Heck, even a
single page pulled from trunk, inline on the project homepage would be
wonderful. Equally a wiki would be great, it would allow this use case
and more : but a wiki is not intrinsically valuable in this way.
https://edge.launchpad.net/subunit is a good page to look at to see how
bland 'here is my <foo>' looks at the moment.
welcome-message
*** Legendario <kemel.zaidan {_AT_} ubuntu-sp.org>
1. As an administrator of a LoCo team, I would really like a tool to send a
standard welcome message for the member after his approbation. It's really
weird the need of typing it again every time I have to approve someone.
wiki
*** Jacob Peddicord <jpeddicord {_AT_} ubuntu.com>
1) Wiki! Bazaar-backed would be nice.
*** Michael Terry <michael.terry {_AT_} canonical.com>
1 Project wiki
*** Eric Nathan Hickman <eric.nathan.hickman {_AT_} gmail.com>
2)Wiki
*** Przemek Kulczycki <przemekkulczycki {_AT_} gmail.com>
1) Project wiki
*** Wolfgang Silbermayr <wolfgang.silbermayr {_AT_} gmail.com>
2) Wiki
*** Tim McNamara <paperless {_AT_} timmcnamara.co.nz>
1) Wiki / Documentation facility
*** Gavin Panella <gavin.panella {_AT_} canonical.com>
1. Wiki, backed by Bazaar preferably. Defintely not MoinMoin :)
*** Jamie Bennett <jamie {_AT_} linuxuk.org>
2. Project Wiki.
*** Graham Binns <graham {_AT_} canonical.com>
1. Bazaar-based wiki
*** Andrea Corbellini <andrea.corbellini {_AT_} beeseek.org>
2. Version controlled wiki.
*** Christopher Armstrong <radix {_AT_} twistedmatrix.com>
1. Some sort of web hosting for projects. A wiki would be fine.
*** Alex Launi <alex.launi {_AT_} gmail.com>
1) An integrated wiki
*** David McNally <david3333333 {_AT_} gmail.com>
1) Wiki!
*** nazo <lovesyao {_AT_} gmail.com>
2) Wiki for projects, teams and personals
*** Xavier Maillard <xma {_AT_} gnu.org>
3. bzr-based wiki (whith interactions with point 1 ;))
*** "Coke" on IRC, channeled via Martin Pool <mbp {_AT_} canonical.com>
1. A wiki, including a place to host screenshots
*** Magnun Leno <magnun.leno {_AT_} gmail.com>
1. A wiki
*** Jamu Kakar <jkakar {_AT_} kakar.ca>
1. Project wiki and static hosting
For pretty much every project I have on Launchpad, I'd like to be
able to (1) manage project documents using a wiki and (2) provide
static generated content such as API documentation. I'd like to
be able to use the wiki format in places like the product
description and summary, so that I can link into my content from
standard Launchpad pages.
*** Michael Hudson <michael.hudson {_AT_} canonical.com>
1) Some kind of wiki/doc/sphinx hosting thing.
*** Michael Hofmann <mh21 {_AT_} piware.de>
2) wiki support to create more elaborate home pages/support wikis
*** Jan-Marek Glogowski <glogow {_AT_} fbihome.de>
2. Integrated wiki (and wiki syntax for most textbox fields
like description, bugtracker, ...)
*** Robert Collins <robert.collins {_AT_} canonical.com>
Secondly, I would _love_ the ability to have docs of some sort visible
in my projects. I don't particularly care about vhosts or anything like
that. Markdown, or Sphinx. Or ReST - all good. There are cross site
attack implications here, so its likely we'd *need* vhosts, but thats a
different discussion. Currently there is no where that I can go to put
online browsable documentation such as HOWTO's and intros. Heck, even a
single page pulled from trunk, inline on the project homepage would be
wonderful. Equally a wiki would be great, it would allow this use case
and more : but a wiki is not intrinsically valuable in this way.
https://edge.launchpad.net/subunit is a good page to look at to see how
bland 'here is my <foo>' looks at the moment.
*** Jelmer Vernooij <jelmer {_AT_} samba.org>
3) Wiki
workflow-unification
*** Jamu Kakar <jkakar {_AT_} kakar.ca>
3. Unify bug/code review user experience
On pretty much all the projects I work on the bug tracker is the
place where we keep track of things that need to be done to make
the code or the project better. Every code-related task starts
by finding or filing a bug, assigning it to oneself and marking
it as 'In Progress'. From there, a branch is created, eventually
going through a review process before being merged. At that
point the bug is closed. The current separation of merge
proposals and code reviews from bug reports makes it awkward to
follow the details of a problem from the initial report,
discussions about the issue and potential solutions, (typically
one) proposed branches and associated reviews, to the final
changes landing. I would like to be able to look at a bug in my
web browser and be able to see the whole set of interactions that
happened around it, without needing to jump around from the bug
to individual merge proposals.