it seems the message of our move of issue tracking to GitLab is slowly
spreading and we're seeing a steady flow of new reports in our
inkscape/inkscape issue tracker on Gitlab
As most of us had the opportunity to get some first-hand experience with
the new issue tracking by now and with the amount of bugs still being
manageable, it seems to be a good time to discuss and decide on some
guidelines for this tracker, so we can make most efficient use of it.
Having worked with the tracker fo some time here's my list of items (in
no particular order) that I feel need attention. Please add to it as
needed and most importantly discuss, so we can find solutions that work
well for all of us. (We can obviously break individual topics out into
GitLab issues eventually, once we have set a rough direction).
On Launchpad (LP) we used Milestones for targeting bugs (only
occasionally, though) but more importantly for tracking in which
release a fix landed. The latter seems of particular importance, as
release notes rely on it heavily.
I suggest to continue this practice and expand it to merge requests.
However this requires us all to make sure to actually set milestones
properly. Currently we often just close bugs without giving it
further thought (GitLab even does that automatically for us if a
suitable commit message is used), which would make it almost
impossible to keep track of the issues fixed in a particular
release. Even more so for MRs...
I feel that we need some mechanism to prioritize bugs. What is your
take on creating a set of prioritized labels of the form
"Importance: High" to replace LPs importance field?
I propose to use "Critical -> High -> Medium -> Low". Even above
critical I'd put the already existing label "Blocker". At the end of
the list I'd rank "Feature request". Does this sound reasonable? Or
is it too fine grained? Is handling "Blocker" and "Feature request"
as additional importance labels fine or should they be separate?
o A general question is what labels we want to apply and how many
there should be. I'm a bit torn here, as a short list makes it
easier to keep track of the existing labels and avoids similar
issues being tagged differently, especially if there are
multiple similar choices or one tag is a sub/superset of
another. A longer list would help us categorize issues better
though. (For example: Do we want a tag for every packaging
option we have, e.g. AppImage, Flatpak, msi, exe, Windows Store,
...? Do we want a tag for every Linux distribution or just a
single "Linux" tag?).
o Another question is if we want to categorize them (e.g.
"OS/Linux", "OS/Windows", "OS/Mac") or if we strip the
category? The former ensures similar tags are sorted together
(otherwise they're sorted alphabetically) and *if* one remembers
the category name it makes it easy to get all relevant tags by
simply typing "OS", but then again tagging with just "Windows"
seems more natural and the category might add noise. Also it
obviously requires some thought in order to create useful
categories (in contrast to just applying "random" tags that fit
and creating new ones on-the-fly). As I'm somebody who likes
order I tend to prefer categorization, but this is something I'd
like your opinion on. (Important note: The search is clever
enough to give you "OS/Windows" if you search for "win").
*On LP we had a detailed status field (new, confirmed, triaged, in
progress, fix commited, fix released - also: incomplete, opinion,
invalid, won't fix). Which of those do we want to replicate in
GitLab (and how?). We could obviously create a label for each of
them, but I have a feeling without a dedicated field it'd not be
o "new/confirmed" should be covered by "inkscape/inkscape" vs
"inkscape/inbox". Only confirmed issues should ever end up in
"inkscape/inkscape" (everything else should be confirmed or
moved to the inbox for triaging).
o "triaged" would be replaced by the presence (or absence) of an
"Importance:" label should we choose to use them.
o "in progress": We already have a corresponding label and could
use it. Alternatively we could define that all assigned bugs are
"in progress" (i.e. only assign bugs if the assignee is going to
work on them eventually; un-assign otherwise)
o "fix commited/fix released": I don't know how to replicate this
reasonably. Is it even required?
o "incomplete": We have "Need info" but such bugs should usually
not be kept in "inkscape/inkscape" for extended periods of time
(if the info is not given, close or move back to "inbox")
o "opinion": should never exist in "inkscape/inkscape"
o "invalid": Do we need a label? Or shall we just close in this
case and forget about it?
o "won't fix": should usually not make it into "inkscape/inkscape"
- do we want a label or shall we just close (i.e. same question
as as for invalid?)
As suggested above we could use the assignee field to put devs who
are going to work on an issue eventually (i.e. indicate "this issue
is being looked into / will be looked into shortly").
Alternatively we could use it to indicate devs who are likely to be
able to fix the issue and are most suited for detailed triaging and
further investigation (i.e. indicate "we know somebody who might be
able to help, please wait until they find the time to check"). This
could be used to distribute and direct the workload a bit. However
we can likely do that with simple @mentioning?
Sorry for the long text (I hope you all read up to this ;-)), it
certainly got longer than intended... I'm looking forward to your
Our monthly board meeting is scheduled for Friday, Mar 1st,
at 10am Pacific in #inkscape-devel. All members are welcome.
We'll be going over recent activities with infrastructure transitions
and sponsors, discuss expansion of staff for Board duties, and
final prep-work for the upcoming hackfest in Pasadena.
** Instagram: https://www.instagram.com/inkscapeofficial/
** mailman3 status
** Wiki migration
** Weblate service deployment
** Using gitlab issues for tracking
** Renewal of old sponsors
** 2 new bronze, 1 gold, 1 tbd
** SFC bookkeeping is still slow
** Sponsor acceptance policy
** Sponsor soliciting / outreach
* Should we set up some new teams under delegation from the board?
** Funding - Fundraisers, merchandising, sponsorship management, etc.
** Accounting - Travel & other reimbursements
** Legal - Trademarks, etc.
* Hackfest [http://www.socallinuxexpo.org/scale/17x/ SCALE]
** Review agenda
*** Ideas to present to Bradley?
** Calls for donations
* Hackfest [http://libregraphicsmeeting.org/2019/ LGM 2019]
** May 30th-June 3rd (Saarbrucken, Germany)
** Next steps for organizing it
** Mentors needed
** Guiding prospective students
** Project ideas list
** Development starter docs
* Other Business
Action Items from last meeting:
== Hackfest LGM Saarbrucken ==
♢ ACTION: Arrange vote for funds for stickers for the two 2019 hackfests [bryce]
=== Merchandise Sales ===
♢ ACTION: Email Bryce with evaluation/details about hellotux.com merchandise service, for preparing board vote [crogers]
♢ ACTION: Board vote on hellotux.com [bryce]
=== Bug Tracker Transition ===
♢ ACTION: Write up an orientation web page for new bug triagers, for gitlab migration [Mc]
== Inkscape 1.0 alpha release ==
♢ ACTION: Check in with people doing test case conversion [Tav]
♢ ACTION: ping jimmac/barbara about the symbolic icons for adding the theme to Inkscape [scislac]
♢ ACTION: Plan video for Inkscape 1.0 release [crogers]
=== Inkscape 1.0 Release ===
♢ ACTION: Brainstorm plans for 1.0beta / 1.0 commemorative merch [crogers, tedg]
=== Sponsorship Management ===
♢ ACTION: Find out about the new event insurance from #conservancy [tedg]
♢ ACTION: Generate summary of our financial situation [bryce]
Transcripts of previous meetings:
I just thought of something.
If we have a few years of using chat.inkscape.org with people jumping
in every now and then to ask questions, and then someone joins and
types `@all hello here's some spam!`
We'd be emailing all the people who ever joined the chat and didn't
leave the room (which I figure would be everyone)
Is there a way to turn off the @all functionality for #general and
#inkscape-devel (except maybe for the admin?)
Best Regards, Martin Owens
Just forwarding to the Devel list, for wider audience.
Sent: Sunday, February 03, 2019 10:31 PM
To: Inkscape User Community
Subject: [Inkscape-user] forum guidelines/CoC/complaints
I've previously volunteered to lead an effort to write the rules and
guidelines for the new forum. Except for the rules about selecting staff and
staff responsibilities, I think the community CoC should suffice. So I was just
One thing specifically that I would like in the forum rules is a clear
and concrete method where members can file a complaint and have it fairly heard
In the CoC, apparently all that's available is contact Krzysztof
Kosiński: tweenk.pl@...2620... Unless the complaint is about a moderator, in
which case members are supposed to contact the Board.
First question - Why is it a different process for complaints about
2nd - Can I at least say that Krzysztof Kosiński has some training and
experience in conflict resolution? Or do we have other community members with
such qualifications, who could do this for the forum?
Inkscape-user mailing list
I am Tej Sukhatme, from BITS Pilani, India.
I am new to development in general and want to start with developing
What are your suggesti0ons ?
Which bug should i start with?
and how do I go about understanding the codebase?
I currently know C++ and little of GTK+. What else do I need to know?
As per the subject line I often notice that what comes out of inkscape and
other svg capable editors uses paths to represent circles and other simple
shapes. I suppose this is for some reason of code optimization (i.e code
optimization in the editor not in the output SVG).
Can anyone shed any light on this?
As the new forum is rapidly being finished, it's probably a good time to
formalize the rules and guidelines for it. If anyone is interested in helping
to draft this document or documents, please reply here.
Once we have a group, we'll decide exactly how we want to handle this.
When we started on this a couple of years ago, we used FramaPad, which allows
users to edit documents live. I found it had the basic features that we needed.
Or I think there are other similar types of sites. Although I'd be just as
happy to be more old school, and exchange ODT or DOC files. But we can decide
as a group.
There aren't really any requirements to participate. Just care about
the forum and how it functions :-)
One still-open question for our migration to gitlab is what to do with
wishlist bugs / feature requests / blueprints. I've filed a ticket in
gitlab for discussing this:
Please share your thoughts on the gitlab issue or here on the mailing
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction usage in
the TextToolbar. It seems that the only sticking point is the use of the
Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do that, I
just wondered if we had considered using the standard GtkFontButton (
This would provide a summary of the font face and size, but would pop-up a
font-chooser dialog (
rather than providing an entry in a combobox. This could result in a less
cluttered toolbar, but I suspect there might be some "clever things"
going on in our font support, and I don't want to break anything without