Developer Meeting Notes 31st May 2024
Hey fellow Developers,
Event: https://inkscape.org/cals/event/1/ Attending: Marc, Adam, Martin, Ishaan, Jonathan, Mikekov, Vaibhav, Rafael Next event: Sat June 8th
We talking about quotation marks and spelling reform in European languages. This was just a bit of fun while wiating for people to join.
---------
Jonathan starts of the meeting by sharing a link to the Working Group policy document. The PDF file was missing from the website so Martin is adding it to the PLC team on the website so everyone can download it and follow the template.
Martin talked about the two pots of powers that the working group policy wants to help define. The first is the powers that the project leadership comittee vests int he team regarding things like spending money and using the trademark. Jonathan adds that making a release for example is using (or trading) on Inkscape's mark. The second set of powers are things that anyone from any team could do, but that we want to monopolise those tasks and decisions into the team. For example making and "official" facebook group could be done by anyone, but the vectors team would probably want to monopolise the decision making process for that.
Jonathan: If you want to initalise something, it should be clear who you have to ask and who doesn't have veto power. Martin wants the list of reponsibilities to be more definitive if possible.
The team works through the template for the working group policy to make a draft, each developer was invited to partipate and suggest things:
----------- DRAFT CHARTER --------------
Name of the Working group: Development team Purpose: • Development of the Inkscape software Delegation • Manage and maintain the Inkscape git repository (i.e. deciding what gets merged, creating protected branches) • Decide about the build system (which systems developers can work on, which systems are supported) • Decide about dependencies, technical consultation with up- and downstream projects • Schedule, perform and publish all release stages, assess the stability of the release • Paid development affecting the Inkscape git needs to consult the dev team first before going to the PLC Additional Responsiblities: • Manage the CI infrastructure and configuration • Point of contact for vulnerability reporting
• Onboarding new developers who want to contribute, provide developer mentorship (internally or through programs like Google Summer of Code, Outreachy) • Maintain developer-facing documentation, including Getting Started resources
Interactions with other teams / working groups: • informing the Documentation team about relevant changes for releases, such as new or changed features • coordinate with the Testing team to maintain the bugtracker(s), make decisions about available tags, priorities / schedule • changes in the user interfaces should be coordinated with the UX team
Meetings and (internal) communication: approx. weekly meeting as video call, announced at least a week prior on the project calendar; regular communication via chat.inkscape.org in team_devel Decision making process: by consensus of a quorum of 3 or more people Membership criterion: Initial members: Jonathan Neuhauser, Marc Jeanmougin, Martin Owens, Mike Kowalski, PBS, Rafael Siejakowski, René de Hesselle, Tavmjong Bah, Vaibhav Malik New members are confirmed by at least two current members. After two years of inactivity, members can be removed.
----------- END CHARTER --------------
The plan is to draft this over the comming week and make a decsion about the WG charter. Please get in touch if you have comments and suggestions.
--------------
Developer activity:
Vaibhav wanted to talk with Mikekov about the font collections, the team discusses how stable 1.4 is and what issues we're fixing and targeting for the release. He worked on a bunch of UI fixes. Addressing a freeze in the file selector dialog. Most of the program hours are consumed, will be reporting to Martin tomorrow for the blog post. Jonthan is jumping into fixing C++ bugs and is mostly done with the work he wanted to do on extensions. Martin has been working mostly on the color branch and fixing some issues with the bug accelerator program, not many hours used this month. Mikekov asked about clipping colors. Mikekov trying to work on the proposal from adam for fill and stroke styles. A couple of MRs and Martin wanted to talk about sp_desktop_style Rafael, some time into the sp-marker refactoring. Rewriting how sp- shapes create markers with about half the amount of code. The goal is to fix a lot of the issues and write tests and also improve the speed of the drawing system. There is still a lot of work for future reafactoring. Ishaan has been investigating how cairo draws lines. How the device scaling works.
Big thanks to everyone who came and stayed the extra time to process the charter with us.
Best Regards, Martin Owens
Hi all,
for the section
"Interactions with other teams / working groups"
I'd like to ask you to also include:
* Translators (coordination of string freeze and other translation-related matters) and * Vectors (coordination of news items, social media posts, releases and other outreach-/marketing-related matters, About Screen). Especially the part about devs being the sole group involved with release publishing according to your current draft makes it look like you want to make releases without announcements, and without involving and informing the marketing team...? This is most likely not what you mean.
---------
Additionally, I'd like you to consider engaging Testers, UX and Bug team with helping to judge the stability of a release and to identify blockers. They are often closer to the user base due to their support roles, and may know better how something may affect users who are not thinking like developers (i.e. who do not know about the underlying SVG specs and technical processes).
---------
As for the documentation team part, I'd be interested to learn about your plans for making that work, sounds great!
Currently, my method for writing the release notes is very cumbersome, and the information that is available is (while it has gotten better, thanks to MRs being required and devs sometimes posting images of their new features) still pretty scarce, so it basically means I have to try everything out. Even to know whether something is a regression only occurring in a dev branch or an actual bug in a released version, I need to test it, or ask, because that information is often not accessible / not available (for the current 1.4 release notes, I've given up trying to document fixed bugs for this reason, it's just not feasible with the time I can invest into this).
For the tutorial updates, man page and keyboard shortcuts updates, I need to rely on the merge request grinding work I do for the release notes, as there are no special 'markers' (e.g. gitlab tags) for it, nor would devs currently remember to tell the docs team about required changes (I think some don't even know those documents exist and need to be updated when something was changed, and that there exists a bug tracker for docs).
So, to summarize, there's a lot of potential to improve the flow of information. Let us know your thoughts about what would be feasible!
My ideas for steps towards improving this would be:
* Dev training sessions: That could potentially help with the translation-related issues that reoccur with every release, and with learning which other team will need which information when you make a change to the code.
* Or at least a set of checkboxes in the MR template could be useful (needs documentation, bug fix (vs. regression fix), with version number, if available)
* The optimal way (as in 'dream') of this would be that someone creates a bug report in docs for anything that needs documentation, like it is done in other projects and professional environments.
For translations: * maybe a job that shows people which new strings they've been adding, so they can check whether they really want to add e.g. '0' to po files for translation. Maybe something that creates a warning, but not an error, so people would check the log. Or a bot that posts it to the MR discussion.
Thanks for listening, Maren
Am 31.05.24 um 20:41 schrieb Martin Owens:
Hey fellow Developers,
Event: https://inkscape.org/cals/event/1/ Attending: Marc, Adam, Martin, Ishaan, Jonathan, Mikekov, Vaibhav, Rafael Next event: Sat June 8th
We talking about quotation marks and spelling reform in European languages. This was just a bit of fun while wiating for people to join.
Jonathan starts of the meeting by sharing a link to the Working Group policy document. The PDF file was missing from the website so Martin is adding it to the PLC team on the website so everyone can download it and follow the template.
Martin talked about the two pots of powers that the working group policy wants to help define. The first is the powers that the project leadership comittee vests int he team regarding things like spending money and using the trademark. Jonathan adds that making a release for example is using (or trading) on Inkscape's mark. The second set of powers are things that anyone from any team could do, but that we want to monopolise those tasks and decisions into the team. For example making and "official" facebook group could be done by anyone, but the vectors team would probably want to monopolise the decision making process for that.
Jonathan: If you want to initalise something, it should be clear who you have to ask and who doesn't have veto power. Martin wants the list of reponsibilities to be more definitive if possible.
The team works through the template for the working group policy to make a draft, each developer was invited to partipate and suggest things:
----------- DRAFT CHARTER --------------
Name of the Working group: Development team Purpose: • Development of the Inkscape software Delegation • Manage and maintain the Inkscape git repository (i.e. deciding what gets merged, creating protected branches) • Decide about the build system (which systems developers can work on, which systems are supported) • Decide about dependencies, technical consultation with up- and downstream projects • Schedule, perform and publish all release stages, assess the stability of the release • Paid development affecting the Inkscape git needs to consult the dev team first before going to the PLC Additional Responsiblities: • Manage the CI infrastructure and configuration • Point of contact for vulnerability reporting
• Onboarding new developers who want to contribute, provide developer mentorship (internally or through programs like Google Summer of Code, Outreachy) • Maintain developer-facing documentation, including Getting Started resources
Interactions with other teams / working groups: • informing the Documentation team about relevant changes for releases, such as new or changed features • coordinate with the Testing team to maintain the bugtracker(s), make decisions about available tags, priorities / schedule • changes in the user interfaces should be coordinated with the UX team
Meetings and (internal) communication: approx. weekly meeting as video call, announced at least a week prior on the project calendar; regular communication via chat.inkscape.org in team_devel Decision making process: by consensus of a quorum of 3 or more people Membership criterion: Initial members: Jonathan Neuhauser, Marc Jeanmougin, Martin Owens, Mike Kowalski, PBS, Rafael Siejakowski, René de Hesselle, Tavmjong Bah, Vaibhav Malik New members are confirmed by at least two current members. After two years of inactivity, members can be removed.
----------- END CHARTER --------------
The plan is to draft this over the comming week and make a decsion about the WG charter. Please get in touch if you have comments and suggestions.
Developer activity:
Vaibhav wanted to talk with Mikekov about the font collections, the team discusses how stable 1.4 is and what issues we're fixing and targeting for the release. He worked on a bunch of UI fixes. Addressing a freeze in the file selector dialog. Most of the program hours are consumed, will be reporting to Martin tomorrow for the blog post. Jonthan is jumping into fixing C++ bugs and is mostly done with the work he wanted to do on extensions. Martin has been working mostly on the color branch and fixing some issues with the bug accelerator program, not many hours used this month. Mikekov asked about clipping colors. Mikekov trying to work on the proposal from adam for fill and stroke styles. A couple of MRs and Martin wanted to talk about sp_desktop_style Rafael, some time into the sp-marker refactoring. Rewriting how sp- shapes create markers with about half the amount of code. The goal is to fix a lot of the issues and write tests and also improve the speed of the drawing system. There is still a lot of work for future reafactoring. Ishaan has been investigating how cairo draws lines. How the device scaling works.
Big thanks to everyone who came and stayed the extra time to process the charter with us.
Best Regards, Martin Owens _______________________________________________ Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
participants (2)
-
Maren Hachmann -
Martin Owens