''See the [[Wishes|Wishes]] page for what this is all about.'' == answers-attachments == {{{ *** Oleg Koptev 1) ability to attach files in Answers section. }}} == answers-comment-without-changing-state == {{{ *** Steve McInerney 2. be able to comment to an answers without the status changing to either answered or more-information }}} == answers-localization == {{{ *** Nasir Khan Saikat 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 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 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 3) Enhanced browsing for new projects - possibly ala Sourceforge - in a categorical directory }}} == api-event-stream == {{{ *** Gavin Panella 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 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 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 2. Improved Blueprints (Comments, Revision History) }}} == branch-to-email-linkage == {{{ *** Vincent Ladeuil 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 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 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 • 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 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 2. Make status from other bug trackers working better (especially with the Debian BTS) *** Graham Binns 2. Better syncing with remote bug trackers. }}} == bugs-hug-day-tag == {{{ *** Franczen Attila - 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 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 - 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 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 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 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 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 , 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 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 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 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 1. Register my upstream bug tracker identities in launchpad to allow me to hit a "forward this upstream" button. }}} == bugs-versions-affected == {{{ *** Micah Gersten 1. Versions for bugs (Affected versions [Maybe Multiple], Fixed Version) }}} == bugwatcher-frequency == {{{ *** Andreas Moog 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 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 2) Ability to build packages by pushing a Bazaar branch *** James Westby 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 3. Use bzr-svn for svn imports. }}} == bzr-stats == {{{ *** "Coke" on IRC, channeled via Martin Pool 2. Download/branch counts for bzr branches }}} == bzr-writes-via-web == {{{ *** Jacob Peddicord 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 3. Integrated calendar and schedule support. }}} == code-review-improvements == {{{ *** Vincent Ladeuil 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 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 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 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 1. Debian packages in PPA (see bug 188564) *** Andrew SB 3. Debian PPAs - https://bugs.launchpad.net/soyuz/+bug/188564 *** John McCabe-Dansted 2) I agree that Debian packages in PPAs would be nice. }}} == delay-reduction == {{{ *** Vincent Ladeuil 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 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 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 ' looks at the moment. *** Dmitrijs Ledkovs 2 generated documentation hosting per series/milestone. *** nazo 3) API references for distribution's libraries (use *-doc packages?) }}} == do-less-be-smaller-be-smoother == {{{ *** Matthew Paul Thomas 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 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 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 - faster load of the page: it really annoys me, that it is this slow. *** Andrew SB 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: *** Michael Hudson 2) Better performance. *** Maris Fogels • I wish the site was much, much faster. }}} == git == {{{ *** Julien Lavergne 3. Git native support in code hosting (btw, 1 and 2 have very higher priority in my wishes than 3 :)) *** Wolfgang Silbermayr 1) Git support for code *** Michael Hofmann 1) native git hosting 2) [...] 3) native git hosting again :-) *** Jan-Marek Glogowski 3. Code hosting with native Git support }}} == hardware-database == {{{ *** Alan Pope 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 1, 2 and 3 - Localized web ui. Is LP translatable at all? *** SkyMan 1. Multilingual Lauchpad UI (Translations at the first) *** Jan-Marek Glogowski 1. i18n of the UI *** Legendario 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 1. a option to use launchpad in users native language. }}} == log-in-by-username == {{{ *** Jacob Peddicord Also, because it's minor: 4) Ability to login using your ~username instead of email address. This annoys me to no end. *** David McNally 2) login with username, not email }}} == mailing-list-improvements == {{{ *** Przemek Kulczycki 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 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 2 Allow simple markup in project descriptions (links, lists) }}} == merge-proposal-diff-updates == {{{ *** Mirco Müller 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 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 3) better interface... something with little animations, perhaps? (something like in the example at http://www.markshuttleworth.com/archives/239 ) }}} == news-feeds == {{{ *** Tim McNamara 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 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 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 3)Do something about the launchpad email noise maby, turn off notifications for duplicate bugs check box ; ) *** Graham Binns 3. Better management of my mail notifications so that I don't feel like I'm trying to sip from a firehose. *** Christopher Armstrong 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 3) Configurable email preferences to cut down some of the noise, and make the noise more easily automatically sortable }}} == openid-login == {{{ *** Wolfgang Silbermayr 3) Allow OpenID login }}} == paste == {{{ *** Gavin Panella 2. Paste-bin, authenticated, with the ability to link/attach pastes to comments in bugs, merge-proposals, answers, etc. *** Andrea Corbellini 3. Pastebin (just a tiny UI to the librarian would be OK for me). }}} == personal-dashboard == {{{ *** Andrew SB 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 2. http://www.ubuntustats.com/ type thing but personalised for me, based on my projects, teams, bugs etc *** Alex Launi 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 1. Arbitrary lists of bugs (akin to milestones, but personal lists) *** Michael Hudson 3) More task management/personal dashboard stuff. *** Ali Sabil 2) A dashboard/control-center for the logged in user showing information relevant to him/her like recent commits, bug activities *** James Westby 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 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 [ 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 4) A pony. Oh, go on. }}} == ppas-show-official == {{{ *** John McCabe-Dansted 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 3. Better Project Management -- Timelines, Tasks, Roadmaps, Calendar *** Julian Edwards 3. Timelines, Gantt charts and resource management }}} == questionnaire == {{{ *** nazo 1) Questionnaire feature like Google Docs Forms }}} == real-time-commenting-editing == {{{ *** Tom Berger 1. Real-time commenting / editing (think Wave). }}} == realtime-notification-like-xmpp == {{{ *** Christopher Armstrong 3. An IRC bot that mentions tip changes on launchpad-hosted branches. :-) *** Xavier Maillard 1. XMPP notifications and interactions with most part of a project (bug comment, adding new bug repots, ...) }}} == release-automation == {{{ *** Martin Pool 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 2) wildcards in search field }}} == searching-ranking == {{{ *** Tom Berger 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 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 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 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 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 2. Make available suggestion strings to be proposed from dictionary (translation tool,  third party maybe). It's like premoderated autotranslation.  }}} == translations-categorization == {{{ *** Alexey Balmashnov 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 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 2. in the online translation there should a option to suggest the glossary. like it is available in Facebook  translation. *** Diego Donati [...] -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 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 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 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 3) ability to import qt4 translation files (.ts) }}} == translations-ui == {{{ *** Kenneth Nielsen 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 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 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 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 3) Better overall design, currently the different sections of launchpad look very similar and thus very confusing }}} == ui-navigating-to-code == {{{ *** Maris Fogels • 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 1 webhosting formatted reST docs from bzr branch. *** Xavier Maillard 2. reST homepage for a project *** Robert Collins 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 ' looks at the moment. }}} == welcome-message == {{{ *** Legendario 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 1) Wiki! Bazaar-backed would be nice. *** Michael Terry 1 Project wiki *** Eric Nathan Hickman 2)Wiki *** Przemek Kulczycki 1) Project wiki *** Wolfgang Silbermayr 2) Wiki *** Tim McNamara 1) Wiki / Documentation facility *** Gavin Panella 1. Wiki, backed by Bazaar preferably. Defintely not MoinMoin :) *** Jamie Bennett 2. Project Wiki. *** Graham Binns 1. Bazaar-based wiki *** Andrea Corbellini 2. Version controlled wiki. *** Christopher Armstrong 1. Some sort of web hosting for projects. A wiki would be fine. *** Alex Launi 1) An integrated wiki *** David McNally 1) Wiki! *** nazo 2) Wiki for projects, teams and personals *** Xavier Maillard 3. bzr-based wiki (whith interactions with point 1 ;)) *** "Coke" on IRC, channeled via Martin Pool 1. A wiki, including a place to host screenshots *** Magnun Leno 1. A wiki *** Jamu Kakar 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 1) Some kind of wiki/doc/sphinx hosting thing. *** Michael Hofmann 2) wiki support to create more elaborate home pages/support wikis *** Jan-Marek Glogowski 2. Integrated wiki (and wiki syntax for most textbox fields like description, bugtracker, ...) *** Robert Collins 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 ' looks at the moment. *** Jelmer Vernooij 3) Wiki }}} == workflow-unification == {{{ *** Jamu Kakar 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. }}}