== Launchpad == It is not very practical to keep our bugs to lp, for several reasons :
* The integration in both directions is non-existent : while we could, on lp, use stuff like "bzr commit --fixes lp:123456", and commit/bugs would link one to the other, and while gitlab MR and bugs can also be linked (https://docs.gitlab.com/ce/user/project/issues/closing_issues.html#via-merge...) ; using separate platforms prevents us to use either of those and forces to link manually bugs urls in MR and commit URLs in bug comments.
* It is unintuitive to new contributors. They have to subscribe on two different -- non-integrated -- platforms, with different logins (AND lp logins is more confusing since it uses "ubuntu one login")
IMO It would be very good to migrate bugs to gitlab (see below).
== Bugs management in general == During a session about "managing lots of bugs", I learned a few tricks that could be of use:
Bug management was also discussed a lot in that session and the advice that comes most is basically "when in doubt, respectfully close the issue. A user with a closed issue because of lack of details can always reopen it simply with those details, but an issue lacking information left open will drown in an ocean of issues". Migration may help us with sorting issues that have been taken care of, unreproducible ones, wishlist items, and such (see below).
A guy from Gitmate (https://gitmate.io) also talked about it and it looked interesting(also, free for OSS) : basically, automated duplicate bug detection and ability to automatically contact devs with interest in the issue (e.g. contacting one dev for issue about text, or another for crashes or problems in Selection…)
== Wishlist bugs == - Opensuse uses a different system for managing feature requests (https://features.opensuse.org/) and actual bugs. It helps them keep the discussions on a different platform, and clearly manage them with votes, discussions, different teams, tags, etc. Overall, considering the different needs for those two different uses of a bugtracker, I was rather fond of the idea. For Inkscape, since we have the option to make "templates" to fill bugs, I would be in favor of making a new inkscape sub-project in gitlab, just for feature requests. That way, we would have the possibility to have devs subscribed to the "bugs" to get the notifications about bugs well separated from feat requests, and have community members interested about features requests able to only get the discussions about them. Also, the set of tags or the default template to fill in would be very different and they would not appear on the same "list" of issues.
== Migration ==
How I would propose to go about the migration would be to basically post on every one of the 4500 open bugs on lp a closing message with an invitation to try to reproduce the bug with the devel version (maybe with a link to a page explaining how to try it [e.g. Ubuntu with apt, other linux compiling, windows with downloading the latest built 7z]) and if it can be reliably reproduced, to submit it on gitlab and close the issue on lp (or, if wishlist, submit it to the wishlist project). Distributing the task on the bug reporters may help a lot with the initial triaging, and (I'm an optimist) make for a smooth transition.