February 2019 - Inkscape Devel

by Patrick Storz

Hi all, 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 (https://gitlab.com/inkscape/inkscape/issues). 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). * *Milestones:* 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... * *Importance:* 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? * *Labels: * 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"). * *Status *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 used consistently. One idea: 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?) * *Assignee* 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 opinions, though! Cheers Patrick

4 years

6
20
0 / 0

Board meeting Friday Mar 1st at 10am Pacific

by Bryce Harrington

Our monthly board meeting is scheduled for Friday, Mar 1st, at 10am Pacific in #inkscape-devel. All members are welcome. http://wiki.inkscape.org/wiki/index.php/Board_Meetings 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. Agenda: ------- * Infrastructure ** Instagram: https://www.instagram.com/inkscapeofficial/ ** mailman3 status ** Wiki migration ** Weblate service deployment * Sponsorship ** 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 * GSoC ** 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: --------------------------------- http://alpha.inkscape.org/board/meetings/transcripts/ Bryce

4 years

1
1
0 / 0

At all on rocket chat inkscape-user

by unknown＠example.com

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

4 years, 1 month

4
3
0 / 0

Fw: [Inkscape-user] forum guidelines/CoC/complaints

by brynn

Just forwarding to the Devel list, for wider audience. Thanks, brynn -----Original Message----- From: brynn Sent: Sunday, February 03, 2019 10:31 PM To: Inkscape User Community Subject: [Inkscape-user] forum guidelines/CoC/complaints Hi Friends, 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 reviewing it. 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 and settled. 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 moderators? 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? All best, brynn _______________________________________________ Inkscape-user mailing list Inkscape-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user

4 years, 1 month

3
9
0 / 0

need advice

by TEJ SHIRISH SUKHATME .

Hello, I am Tej Sukhatme, from BITS Pilani, India. I am new to development in general and want to start with developing inkscape. 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? Thanks

4 years, 1 month

2
1
0 / 0

why are circles often represented as two arcs

by bryan rasmussen

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? Mvh, Bryan Rasmussen

4 years, 1 month

3
2
0 / 0

forum rules and guidelines

by brynn

Hi Friends, 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 :-) All best, brynn

4 years, 1 month

2
2
0 / 0

Handling of feature suggestions in gitlab

by Bryce Harrington

Hi all, 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: https://gitlab.com/inkscape/infra/services/issues/22 Please share your thoughts on the gitlab issue or here on the mailing list. Bryce

4 years, 1 month

1
0
0 / 0

Font chooser GtkAction migration

by Alex Valavanis

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 ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)? This would provide a summary of the font face and size, but would pop-up a font-chooser dialog ( https://developer.gnome.org/gtkmm-tutorial/stable/sec-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 asking! Any thoughts? AV

4 years, 1 month

5
8
0 / 0

UX for Inkscape tutorials

by anatoly techtonik

Hi. I'd like to know what do you think about this issue https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1803021 ? -- anatoly t.

4 years, 1 month

3
3
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Inkscape Devel February 2019