Calligra/Meetings/Spring 2014 Sprint/Agenda

Below follows a suggested agenda for the sprint. It's free for anybody to put new items below. The actual contents and order for the agenda will be decided at the sprint. Please also indicate who is behind a certain suggestion. If you are interested in something that has already been proposed and want to add your opinion, then add your name to the list.

Presentations

Presentations of things interesting to the Calligra community. Please state targeted audience.

• Translation problems. How to create translatable strings and not cause problems for translators. i18n contexts and markup language (Dmitry).

Projects

Projects we'll work on in small groups, mostly coding or creating other concrete results.

• Add your project here

Discussions

Discussions about topics, which are relevant to all or a sub group of people. Please state audience and desired result of the discussion.

Development 2.0

(proposed by Jstaniek (talk) 10:37, 18 June 2014 (BST)) ​​ Is it still possible to fund development from contributors' "pockets" (time contributions mostly) AND grow? We need to agree on possible options to engage users and attract investors.

Calligra is a great, respected and unique project, and it's 1.7 M lines of code.

But Calligra is currently a project of two speeds. Some apps achieved ZERO mph. Recently mostly Kexi and Krita push it all forward.

• Growing user base
• Challenges in deployment: insufficient (quality) control, fragmentation on Linux; ideas to address that
• Importance of non-Linux targets: Windows, Mac, Web (cloud?) for the development model (paying customers)
• Review of goals, message, communication channels
• Possible need for loosening connections between Calligra apps (organizational, technical) brings more reality, but it's not loosening connections in the community!

Promoting Calligra Libs for Reuse

There surely are apps out there which would like to support document files as well. E.g. for generating reports. Getting more people use Calligra libs comes with responsibilites (less API/ABI changes), but it comes with users at least.

Automatic Feedback or Submission system for issues

• supporting in-app translation improvements (cmp. "Edit" entry in Wiki pages)
• user could have account with the app

Make sure all possible UI strings can be separately edited

• having empty strings as default for e.g. all tooltips, whatsthis, help context