Dev Meeting Agenda 2012-05-30

Possible agenda items (with notes in red):

Project infrastructure

  • Changing tracker from Trac (hosted by SourceForge) to Redmine (own hosted by PolarFox)
    • Redmine might be better to use, possibility of sub-projects (divide dev wiki from user tutorial wiki e.g.)
    • Repository integration, link to commit ("commit:hash") and source code ("source:src/file/to/link") directly
    • Done.
  • Changing the main repository from SourceForge to Github?
    • Easier to fork for potential contributors ("social coding")
    • Sasy setup for hooks (wrt Redmine for example)
    • The main repository will be changed to github. Changes to that will be pushed to so that gentoo users can keep building their packages. After a few months, when everyone had time to switch to github, the repo will be shut down.
    • Until then we will remove commit rights for everyone on to not mess up.
    • jcsogo and hanatos are responsible for the transition, they will announce it on the mailing lists in advance.
  • Financial infrastructure
  • (Automatic builds? suggested by someone in a trac ticket)
    • Currently we will not provide automated builds.
    • We would like to have some automated testing. This will need quite some work though.

"Behavioral change" for the devs

  • Using the tracker
    • dt has grown to an extend where a mailing list and IRC can't keep track of all reported problems any more.
    • Solution would be a consequently used tracker
    • People needed for triaging bugs so we don't fill the tracker with crap; already volunteered: _smn, McBofh
    • _smn and McBofh will form the triaging team and look for other trusted volunteers to help them.
    • The initial triaging of all the tickets in the tracker will be done together in IRC by the triaging team and the devs.
  • Bug triaging guidelines needed

Building an active community

  • The contact page on the website will be redone. The translators should be added, too (ticket #8707).
  • We should add a bot which announces new tickets in #darktable.
  • Providing infrastructure: a wiki, maybe forums for them (served by Redmine)
    • But make clear that we can't do the job for them running it
    • On the users list quite some people seem to be enthusiastic about helping out
    • Providing them some infrastructure to gather and work could do the job
    • We already have an user wiki.
    • We will host a forum for the users. We will however not do the moderation.
    • We should use G+ more to attract users. jcsogo will take care of that.
  • Maybe find volunteers for bug triaging among users
    • See above.
  • Revamp of the styles database?
    • Current approach with wiki page seems not to attract a lot of people
    • Maybe a styles sharing section directly on the website could do better
    • Maybe we (devs) need to dig out our own styles to create a seed
    • Most devs don't use styles at all.
    • We should encourage people to provide images+styles+description.
    • _smn will try to come up with a nice way to upload, view and rate styles.
    • We might even run a competition to find some really good examples and ship them with darktable.
    • Every dev should provide at least one style to kick start the sharing.
    • Maybe one day we should think about supporting GHNS (


  • Triaging day
    • We need to go through all currently open tickets and triage to get a clean start
    • Maybe now maybe another date to meet
    • Postponed, see above.
  • Naming conventions
    • Inconsistent use of "plugins" and "modules" throughout the UI
    • We should decide for one of both and use it for everything
    • "Plugin" could sound a bit "3rd party"-ish, and since we ship all we have you can't de-plug them either
    • Maybe distinction between modules and iops (image operators)?
    • Just call the suckers "module" from now on! (ticket #8708)
  • The official darktable user manual
    • The user manual is terribly, terribly outdated
    • We either need to rework that completely of ditch it in total (not preferable)
    • We need a user manual. The current manual is outdated.
    • Are there volunteers from the user base that want to help writing it?
    • We will move the user manual to the user wiki. This should make it easier to contribute.
    • Instead of copying over all the outdated content we will rewrite it from scratch. Some parts can be taken from the current manual.
    • Problem to solve: How to generate a nice PDF version of the manual from wiki pages?
  • Delete files to trash or not?
    • Trac ticket #115 / Redmine ticket #8385
    • No trash, just /dev/null
  • We will not port darktable to Windows. The only exception is when someone shows up and proves that he's able and willing to maintain that platform. This is not so much about our code base but building and bundling all the libraries we depend on.

Also available in: PDF HTML TXT

Go to top