Hackfest2019 Recap

From Inkscape Wiki
Jump to navigation Jump to search

Recap of Inkscape's Hackfest in Pasadena

Other pages: Hackfest2019 SCALE, [Hackfest2019 Agenda] Hackfest2019 SCALE Topics, Hackfest2019 SCALE Attendees.

We've just completed another great hackfest here in rainy California, and wanted to share some accomplishments of the event.

The 1.0 release plan was fleshed out

  • We will have a chill/frost/freeze sequence beginning March 15th, and will encourage a general focus on critical bugs. We will have a "Final Features" list of a narrow list of allowed features to land before the 1.0 release. A formalized definition of "blocker" bugs, vs "critical" bugs was agreed to, and will be made part of the release process.

The Roadmap will be rejuvenated with a new monthly process

  • Going forward, a new team will be formed to meet monthly and review/approve/forecast feature development work. This meeting will look at both "Big Ideas" that need long range planning, and smaller UX changes that need more than one person to decide. It will also track status of what the extended developer community is up to, and thus help turn the Roadmap into more of a Forecast.

A vision document on our UI strategy

  • We see a need for a collaboratively developed document that lays out our intended design strategy for the UI. We didn't get into details on how to make this happen, though.

A "Big Ideas" tracker will be established in gitlab

  • (We need a better name for this.) These will hold "blueprint" scale feature requests, that will need planning, analysis, and scheduling via the roadmap. We will explore kanban-like approaches for managing this list in building the roadmap.

For Mac OS/X, we want to make initial steps by 1.0

  • Our first objective will be packaging a demo app. This could be a scripted build of gtk3-demo-application, for example; that way if there are problems, it will be more familiar to upstream. If this can be achieved by beta, we may be able to invest more to getting a package ready by 1.0.
  • A follow up would be to convert the raw build script into equivalent CMake commands. This should reveal lessons on how to do this for Inkscape.
  • Additional steps were scoped out, and will need further definition in gitlab. The master bug for this should probably move to the "Big Ideas" tracker at this point.

For CMYK, Color Management, and PDF/Print, we have a detailed plan of development tasks needed.

  • This will be published in the "Big Ideas" gitlab tracker.

We will establish Paypal buttons for dedicated funds to start collection of donations for several targeted efforts:

A. Native Mac OS/X Packaging
B. Color Management
C. Internships promoting diversity (e.g. Outreachy)

Budget planning work was begun

  • Areas of interest for funding include hackfests, increased conference attendance for speakers, increased Vectors team budget, and resources towards increased fundraising and sponsorship management. The board will continue work via email.

A brand/trademark issue exists which needs visibility

  • We will be making this (and things people can do to help) public soon. Preparatory tasks were identified and split up between us.

Video interviews of attendees were collected

  • These videos will provide material for Vectors team outreach and communications efforts in coming weeks and months.

A greeter guideline was conceptualized

  • The initial interactions with a new contributor are critical for getting them happily engaged, and directed to where they want to work. A personal touch counts, so we want actual people doing greeting work. The greeter guideline will give easy reference info that can be given in chat, etc. for how to get involved in different areas.

Teacher curriculum grant program

  • We discussed using grant programs to develop teaching materials for educators to bring Inkscape into the classroom. This felt out of scope for us right now, but we may revisit the idea some day in the future.

Codebase subsystem contacts

  • It can be unclear who to contact for advice when working on certain areas of the code. We will try to identify in per-directory README's the individuals who have experience with that code and who are available to be contacted with questions.