Re: [darktable-dev] How do you feel about code bounties ?

[Aurélien Pierre]

Hi everyone,

just following up on that matter with the results of the poll.

Over the 105 people who responded :

  * 94 % are ready to found the project, some are very enthusiastic,
  * 57 % would do it on a feature bounty basis,
  * 45 % would do it an a recurring basis,
  * 8 % would prefer to found directly the devs on a private basis,
  * we could secure a total yearly amount of nearly 11 000 € (eleven
thousands), that is  an average of 104 ± 483 €/year/user and a max
of 5000 €/year/user
  * we could secure an average total bounty amount of 1527 €/feature,
that is an average of 14 ± 19 €/feature/user and a may of 100
€/feature/user.

That is only for the French-speaking community (France, Switzerland,
Belgium). I feel most are happy to turn the amount of their former
Lightroom subscription into a sponsorship of something forever open and
non-bounding.

What are the news on the senior devs end ?

Have a good day,

Aurélien.


Le 11/09/2018 à 05:30, johannes hanika a écrit :
> hi aurelien!
>
> any help is always appreciated. you should by now have dev access on
> redmine (houz is our admin, he granted you access).
>
> your numbers sound encouraging. 660EUR for a bounty that shouldn't
> take you more than your sunday afternoon to fix sounds like a good
> deal. now we'll also have to work on the conditions of our daytime
> jobs to free up time. this should be possible.
>
> cheers,
>  jo
> On Mon, Sep 10, 2018 at 7:51 PM Aurélien Pierre
>  wrote:
>> Hi Jo !
>>
>> I launched a poll on the french community blog (darktable.fr) to see if a 
>> founding of some sort would get support from users. The poll has been up for 
>> 10 hours, we have for now 42 answers and the good news are :
>>
>> 95 % of users are ready to put money in the project,
>> 2/3 would go for a feature-based bounty founding, 1/3 would go for a 
>> recurring crowdfunding (like Patreon/Liberapay),
>> the average contribution per bounty per founder would be 16 ± 15 € (average 
>> ± 1 std) summing up to 660 €/bounty in total
>> the yearly total participation per founder would be 62 ± 49 € summing up to 
>> 2545 €/year in total (for now)
>>
>> So my question is : if we were to secure a recurring monthly revenue to pay 
>> for seniors/core devs time, would they be able to clear some hours each 
>> month to review code contributions or mentor new devs ? Platforms like 
>> Liberapay allow easily (as far as I know) to split teams earnings between 
>> the team members.
>>
>> Also, if you trusted me enough to give me admin rights on redmine, I would 
>> be happy to merge duplicates or close the solved issues to make some room.
>>
>> Have a good day !
>>
>> Aurélien.
>>
>>
>> Le 10/09/2018 à 08:55, johannes hanika a écrit :
>>
>> hi,
>>
>> thanks for putting this list together! yes we're terrible dealing with
>> these things. time seems to be the limiting factor here. the problem
>> with recruiting new people to go in and fix these things is that you
>> need someone to review the changes. which pretty much amounts to the
>> bottle neck for our github pull requests or google summer of code and
>> the like. now funding a full time employee for a secured amount of
>> time is a completely different story than fixing a bug here and there.
>>
>> i agree that the procedure needs to be changed though. somehow the
>> core issue seems to be senior dev time to me.
>>
>> cheers,
>>  jo
>>
>> On Sat, Sep 8, 2018 at 7:24 AM Aurélien Pierre
>>  wrote:
>>
>> Hi everyone,
>>
>> looking at the Redmine feature requests, it seems that a lot of legitimate 
>> requests are left idle, and some have been so for several years, generating 
>> duplicates. Most of these features are cosmetic User Interface improvements 
>> or making variables writable, such as :
>>
>> delete some EXIF+GPS meta-data in exported files (for privacy)
>> set the export file resolution from paper size and printing DPI, set the DPI 
>> value right in EXIF,
>> add/edit unique names/titles for modules instances, also within styles,
>> decompose the darkroom history by module AND module controls (decrease the 
>> history granularity),
>> add more JPEG exportation options (progressive, optimized, subsampling),
>> apply conditional styles automatically (the same way as the presets of the 
>> modules),
>> make styles hierarchical (to clean-up the list),
>> allow drawn mask edition (size, feathering, opacity) from the masks list and 
>> keyboard input values,
>> lock position and size of drawn masks for safe panning/zooming,
>> EXIF and IPTC management/edition requests (date, time, names of lenses 
>> without processor, scans with no/wrong metadata),
>> create arbitrary collections/catalogs of images (ex : family, perso, 
>> assignments),
>> implement ESC and RETURN shortcuts in every dialog to cancel and validate,
>> implement a coarse/fine tuning option to increment/decrement values with the 
>> mouse wheel
>> lots of small GTK glitches with scroll bars, lighttable selections and 
>> hovers,

Re: [darktable-dev] How do you feel about code bounties ?

[johannes hanika]

hi aurelien!

any help is always appreciated. you should by now have dev access on
redmine (houz is our admin, he granted you access).

your numbers sound encouraging. 660EUR for a bounty that shouldn't
take you more than your sunday afternoon to fix sounds like a good
deal. now we'll also have to work on the conditions of our daytime
jobs to free up time. this should be possible.

cheers,
 jo
On Mon, Sep 10, 2018 at 7:51 PM Aurélien Pierre
 wrote:
>
> Hi Jo !
>
> I launched a poll on the french community blog (darktable.fr) to see if a 
> founding of some sort would get support from users. The poll has been up for 
> 10 hours, we have for now 42 answers and the good news are :
>
> 95 % of users are ready to put money in the project,
> 2/3 would go for a feature-based bounty founding, 1/3 would go for a 
> recurring crowdfunding (like Patreon/Liberapay),
> the average contribution per bounty per founder would be 16 ± 15 € (average ± 
> 1 std) summing up to 660 €/bounty in total
> the yearly total participation per founder would be 62 ± 49 € summing up to 
> 2545 €/year in total (for now)
>
> So my question is : if we were to secure a recurring monthly revenue to pay 
> for seniors/core devs time, would they be able to clear some hours each month 
> to review code contributions or mentor new devs ? Platforms like Liberapay 
> allow easily (as far as I know) to split teams earnings between the team 
> members.
>
> Also, if you trusted me enough to give me admin rights on redmine, I would be 
> happy to merge duplicates or close the solved issues to make some room.
>
> Have a good day !
>
> Aurélien.
>
>
> Le 10/09/2018 à 08:55, johannes hanika a écrit :
>
> hi,
>
> thanks for putting this list together! yes we're terrible dealing with
> these things. time seems to be the limiting factor here. the problem
> with recruiting new people to go in and fix these things is that you
> need someone to review the changes. which pretty much amounts to the
> bottle neck for our github pull requests or google summer of code and
> the like. now funding a full time employee for a secured amount of
> time is a completely different story than fixing a bug here and there.
>
> i agree that the procedure needs to be changed though. somehow the
> core issue seems to be senior dev time to me.
>
> cheers,
>  jo
>
> On Sat, Sep 8, 2018 at 7:24 AM Aurélien Pierre
>  wrote:
>
> Hi everyone,
>
> looking at the Redmine feature requests, it seems that a lot of legitimate 
> requests are left idle, and some have been so for several years, generating 
> duplicates. Most of these features are cosmetic User Interface improvements 
> or making variables writable, such as :
>
> delete some EXIF+GPS meta-data in exported files (for privacy)
> set the export file resolution from paper size and printing DPI, set the DPI 
> value right in EXIF,
> add/edit unique names/titles for modules instances, also within styles,
> decompose the darkroom history by module AND module controls (decrease the 
> history granularity),
> add more JPEG exportation options (progressive, optimized, subsampling),
> apply conditional styles automatically (the same way as the presets of the 
> modules),
> make styles hierarchical (to clean-up the list),
> allow drawn mask edition (size, feathering, opacity) from the masks list and 
> keyboard input values,
> lock position and size of drawn masks for safe panning/zooming,
> EXIF and IPTC management/edition requests (date, time, names of lenses 
> without processor, scans with no/wrong metadata),
> create arbitrary collections/catalogs of images (ex : family, perso, 
> assignments),
> implement ESC and RETURN shortcuts in every dialog to cancel and validate,
> implement a coarse/fine tuning option to increment/decrement values with the 
> mouse wheel
> lots of small GTK glitches with scroll bars, lighttable selections and hovers,
> link exported pictures paths to original RAW files,
> allow to set the UI main color and create user-friendly theme/template 
> (whitout editing CSS),
> etc.
>
> Some are more algorithmically challenging :
>
> make the RGB gains independant in wavelets/non-locals means denoising module,
> rotate/flip the sampling patch in the spot removal module and in the freshly 
> merged retouch module,
> add a color correction on A and B channels to fix the desaturation happening 
> in the local contrast module (laplacian) with heavy settings,
> display the locked AF point on previews
> detecting duplicates and similar pictures in database
> etc.
> plus all the Windows portability issues.
>
> And there are still #TODOs in the source code.
>
> Most of these changes are for sure not the most challenging and don't make 
> for the sexiest coding party, so I have no trouble imagining how little 
> appealing they can be to hobbyist developers, but they are nonetheless useful 
> and game changing for professionnals who are bound to efficiency constraints.
>
> I find quite remarkable the dramatic improvements that 

Re: [darktable-dev] How do you feel about code bounties ?

[Aurélien Pierre]

Hi Jo !

I launched a poll on the french community blog (darktable.fr) to see if
a founding of some sort would get support from users. The poll has been
up for 10 hours, we have for now 42 answers and the good news are :

  * 95 % of users are ready to put money in the project,
  * 2/3 would go for a feature-based bounty founding, 1/3 would go for a
recurring crowdfunding (like Patreon/Liberapay),
  * the average contribution per bounty per founder would be 16 ± 15 €
(average ± 1 std) summing up to 660 €/bounty in total
  * the yearly total participation per founder would be 62 ± 49 €
summing up to 2545 €/year in total (for now)

So my question is : if we were to secure a recurring monthly revenue to
pay for seniors/core devs time, would they be able to clear some hours
each month to review code contributions or mentor new devs ? Platforms
like Liberapay allow easily (as far as I know) to split teams earnings
between the team members.

Also, if you trusted me enough to give me admin rights on redmine, I
would be happy to merge duplicates or close the solved issues to make
some room.

Have a good day !

Aurélien.


Le 10/09/2018 à 08:55, johannes hanika a écrit :
> hi,
>
> thanks for putting this list together! yes we're terrible dealing with
> these things. time seems to be the limiting factor here. the problem
> with recruiting new people to go in and fix these things is that you
> need someone to review the changes. which pretty much amounts to the
> bottle neck for our github pull requests or google summer of code and
> the like. now funding a full time employee for a secured amount of
> time is a completely different story than fixing a bug here and there.
>
> i agree that the procedure needs to be changed though. somehow the
> core issue seems to be senior dev time to me.
>
> cheers,
>  jo
>
> On Sat, Sep 8, 2018 at 7:24 AM Aurélien Pierre
>  wrote:
>> Hi everyone,
>>
>> looking at the Redmine feature requests, it seems that a lot of legitimate 
>> requests are left idle, and some have been so for several years, generating 
>> duplicates. Most of these features are cosmetic User Interface improvements 
>> or making variables writable, such as :
>>
>> delete some EXIF+GPS meta-data in exported files (for privacy)
>> set the export file resolution from paper size and printing DPI, set the DPI 
>> value right in EXIF,
>> add/edit unique names/titles for modules instances, also within styles,
>> decompose the darkroom history by module AND module controls (decrease the 
>> history granularity),
>> add more JPEG exportation options (progressive, optimized, subsampling),
>> apply conditional styles automatically (the same way as the presets of the 
>> modules),
>> make styles hierarchical (to clean-up the list),
>> allow drawn mask edition (size, feathering, opacity) from the masks list and 
>> keyboard input values,
>> lock position and size of drawn masks for safe panning/zooming,
>> EXIF and IPTC management/edition requests (date, time, names of lenses 
>> without processor, scans with no/wrong metadata),
>> create arbitrary collections/catalogs of images (ex : family, perso, 
>> assignments),
>> implement ESC and RETURN shortcuts in every dialog to cancel and validate,
>> implement a coarse/fine tuning option to increment/decrement values with the 
>> mouse wheel
>> lots of small GTK glitches with scroll bars, lighttable selections and 
>> hovers,
>> link exported pictures paths to original RAW files,
>> allow to set the UI main color and create user-friendly theme/template 
>> (whitout editing CSS),
>> etc.
>>
>> Some are more algorithmically challenging :
>>
>> make the RGB gains independant in wavelets/non-locals means denoising module,
>> rotate/flip the sampling patch in the spot removal module and in the freshly 
>> merged retouch module,
>> add a color correction on A and B channels to fix the desaturation happening 
>> in the local contrast module (laplacian) with heavy settings,
>> display the locked AF point on previews
>> detecting duplicates and similar pictures in database
>> etc.
>> plus all the Windows portability issues.
>>
>> And there are still #TODOs in the source code.
>>
>> Most of these changes are for sure not the most challenging and don't make 
>> for the sexiest coding party, so I have no trouble imagining how little 
>> appealing they can be to hobbyist developers, but they are nonetheless 
>> useful and game changing for professionnals who are bound to efficiency 
>> constraints.
>>
>> I find quite remarkable the dramatic improvements that software such as 
>> Blender have known in the past decade, and though I get why dt developers 
>> aren't thrilled by the admin overhead involved in a similar fundation to pay 
>> full-time developpers, I think the above requests will stay idle for some 
>> more time if we don't go next-level. That would be a shame considering the 
>> core is stable and sane, and what is needed is mainly cosmetic.
>>
>> As more and more 

Re: [darktable-dev] How do you feel about code bounties ?

[johannes hanika]

hi,

thanks for putting this list together! yes we're terrible dealing with
these things. time seems to be the limiting factor here. the problem
with recruiting new people to go in and fix these things is that you
need someone to review the changes. which pretty much amounts to the
bottle neck for our github pull requests or google summer of code and
the like. now funding a full time employee for a secured amount of
time is a completely different story than fixing a bug here and there.

i agree that the procedure needs to be changed though. somehow the
core issue seems to be senior dev time to me.

cheers,
 jo

On Sat, Sep 8, 2018 at 7:24 AM Aurélien Pierre
 wrote:
>
> Hi everyone,
>
> looking at the Redmine feature requests, it seems that a lot of legitimate 
> requests are left idle, and some have been so for several years, generating 
> duplicates. Most of these features are cosmetic User Interface improvements 
> or making variables writable, such as :
>
> delete some EXIF+GPS meta-data in exported files (for privacy)
> set the export file resolution from paper size and printing DPI, set the DPI 
> value right in EXIF,
> add/edit unique names/titles for modules instances, also within styles,
> decompose the darkroom history by module AND module controls (decrease the 
> history granularity),
> add more JPEG exportation options (progressive, optimized, subsampling),
> apply conditional styles automatically (the same way as the presets of the 
> modules),
> make styles hierarchical (to clean-up the list),
> allow drawn mask edition (size, feathering, opacity) from the masks list and 
> keyboard input values,
> lock position and size of drawn masks for safe panning/zooming,
> EXIF and IPTC management/edition requests (date, time, names of lenses 
> without processor, scans with no/wrong metadata),
> create arbitrary collections/catalogs of images (ex : family, perso, 
> assignments),
> implement ESC and RETURN shortcuts in every dialog to cancel and validate,
> implement a coarse/fine tuning option to increment/decrement values with the 
> mouse wheel
> lots of small GTK glitches with scroll bars, lighttable selections and hovers,
> link exported pictures paths to original RAW files,
> allow to set the UI main color and create user-friendly theme/template 
> (whitout editing CSS),
> etc.
>
> Some are more algorithmically challenging :
>
> make the RGB gains independant in wavelets/non-locals means denoising module,
> rotate/flip the sampling patch in the spot removal module and in the freshly 
> merged retouch module,
> add a color correction on A and B channels to fix the desaturation happening 
> in the local contrast module (laplacian) with heavy settings,
> display the locked AF point on previews
> detecting duplicates and similar pictures in database
> etc.
> plus all the Windows portability issues.
>
> And there are still #TODOs in the source code.
>
> Most of these changes are for sure not the most challenging and don't make 
> for the sexiest coding party, so I have no trouble imagining how little 
> appealing they can be to hobbyist developers, but they are nonetheless useful 
> and game changing for professionnals who are bound to efficiency constraints.
>
> I find quite remarkable the dramatic improvements that software such as 
> Blender have known in the past decade, and though I get why dt developers 
> aren't thrilled by the admin overhead involved in a similar fundation to pay 
> full-time developpers, I think the above requests will stay idle for some 
> more time if we don't go next-level. That would be a shame considering the 
> core is stable and sane, and what is needed is mainly cosmetic.
>
> As more and more professional photographers adopt dt in their job and are 
> asking for more efficency-driven features, I know that some would be happy to 
> fund developpers to smooth all the sharp edges listed above. For now, the 
> features that the developpers don't need don't stand a chance to appear in 
> the software.
>
> So I found a platform where you could create a bounty for each feature 
> request/bug on Redmine, have users/donators fund the requests they want in a 
> crowdfunding way, hire freelancers to do it, and take care of the payment : 
> https://www.bountysource.com/. You can create a dt group, link it to Github, 
> open/accept/close/pay the bounties, etc. Actually, it seems that darktable 
> has already a project page, but only linked to the Github tracker : 
> https://www.bountysource.com/teams/darktable/issues.
>
> Shouldn't we merge Github issues and Redmine bugs/FR, and promote 
> bountysource ?
>
> Cheers,
>
> Aurélien.
>
>
> ___ 
> darktable developer mailing list to unsubscribe send a mail to 
> darktable-dev+unsubscr...@lists.darktable.org
___
darktable developer mailing list
to unsubscribe send a mail to 

Re: [darktable-dev] How do you feel about code bounties ?

[Edgardo Hoszowski]

For lock position and size  of
drawn masks for safe panning/zooming, you have now a new shortcut to allow
to pan & zoom while editing masks, you can find it on views->darkroom

2018-09-08 2:24 GMT-03:00 Aurélien Pierre :

> Hi everyone,
>
> looking at the Redmine feature requests, it seems that a lot of
> legitimate requests are left idle, and some have been so for several years,
> generating duplicates. Most of these features are cosmetic User Interface
> improvements or making variables writable, such as :
>
>- delete some EXIF+GPS meta-data
> in exported files (for
>privacy)
>- set the export file resolution
> from paper size and
>printing DPI, set the DPI value right in EXIF,
>- add/edit unique names/titles
> for modules instances, also
>within styles ,
>- decompose the darkroom history
>by module AND module
>controls (decrease the history granularity),
>- add more JPEG exportation options (progressive
>, optimized
>, subsampling)
>,
>- apply conditional styles automatically (the same way as the presets
>of the modules),
>- make styles hierarchical (to clean-up the list),
>- allow drawn mask edition 
>(size, feathering, opacity) from the masks list and keyboard input values,
>- lock position and size 
>of drawn masks for safe panning/zooming,
>- EXIF
>
> 
>and IPTC
>
> 
>management/edition requests (date, time, names of lenses without processor,
>scans with no/wrong metadata),
>- create arbitrary collections/catalogs
> of images (ex : family,
>perso, assignments),
>- implement ESC and RETURN 
>shortcuts in every dialog to cancel and validate,
>- implement a coarse/fine tuning
> option to
>increment/decrement values with the mouse wheel
>- lots of small GTK glitches with scroll bars
>
> ,
>lighttable selections  and
>hovers ,
>- link exported pictures paths to original RAW files,
>- allow to set the UI main color and create user-friendly
>theme/template (whitout editing CSS),
>- etc.
>
> Some are more algorithmically challenging :
>
>- make the RGB gains independant
> in wavelets/non-locals
>means denoising module,
>- rotate/flip the sampling patch in the spot removal module and in the
>freshly merged retouch module,
>- add a color correction on A and B channels to fix the desaturation
>happening in the local contrast module (laplacian) with heavy settings,
>- display the locked AF point
>on previews
>- detecting duplicates and similar pictures
>in database
>- etc.
>- plus all the Windows portability issues.
>
> And there are still #TODOs in the source code.
>
> Most of these changes are for sure not the most challenging and don't make
> for the sexiest coding party, so I have no trouble imagining how little
> appealing they can be to hobbyist developers, but they are nonetheless
> useful and game changing for professionnals who are bound to efficiency
> constraints.
>
> I find quite remarkable the dramatic improvements that software such as
> Blender have known in the past decade, and though I get why dt developers
> aren't thrilled by the admin overhead involved in a similar fundation to
> pay full-time developpers, I think the 

Re: [darktable-dev] How do you feel about code bounties ?

[rawfiner]

Hi everyone
In my opinion, it would be nice to be able to fund work on such small
feature requests.
Yet, I think that it should be done with a particular way to ensure that:
- one can only found development for bugs/features that were approved by
the main developers / or by community first
- the developed code is of high quality (for instance, funded developers
may be paid after the code review, to ensure some quality of code)

rawfiner

Le samedi 8 septembre 2018, Andreas Schneider  a écrit :

> On Saturday, 8 September 2018 07:24:51 CEST Aurélien Pierre wrote:
> > Hi everyone,
>
> Hi Aurélien,
>
> > Shouldn't we merge Github issues and Redmine bugs/FR, and promote
> > bountysource ?
>
> I doesn't really make sense to start with bounties while github merge
> requests
> are bit rotting. Even small changes which are easy to review ...
>
>
> Andreas
>
>
> 
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] How do you feel about code bounties ?

[Aurélien Pierre]

Do the (hard)core devs need more help reviewing merge requests ? How
could we solve that issue ?


Le 08/09/2018 à 05:02, Andreas Schneider a écrit :
> On Saturday, 8 September 2018 07:24:51 CEST Aurélien Pierre wrote:
>> Hi everyone,
> Hi Aurélien,
>
>> Shouldn't we merge Github issues and Redmine bugs/FR, and promote
>> bountysource ?
> I doesn't really make sense to start with bounties while github merge 
> requests 
> are bit rotting. Even small changes which are easy to review ...
>
>
>   Andreas
>
>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
>


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] How do you feel about code bounties ?

[Andreas Schneider]

On Saturday, 8 September 2018 07:24:51 CEST Aurélien Pierre wrote:
> Hi everyone,

Hi Aurélien,

> Shouldn't we merge Github issues and Redmine bugs/FR, and promote
> bountysource ?

I doesn't really make sense to start with bounties while github merge requests 
are bit rotting. Even small changes which are easy to review ...


Andreas


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] How do you feel about code bounties ?

[n61...@gmail.com]

I was also perusing redmine and found duplicates and issues which have comments 
the issue should be closed.
I can help either port redmine to github, or help manage the issue database on 
occasion. (I would want rules to follow on how to handle issues).
Lastly, I would also be interested in funding some bounties.
Tim
-- Original message--From: Aurélien PierreDate: Fri, Sep 7, 2018 11:25 
PMTo: darktable;Cc: Subject:[darktable-dev] How do you feel about code bounties 
?

Hi everyone,
looking at the Redmine feature requests,
  it seems that a lot of legitimate requests are left idle, and some
  have been so for several years, generating duplicates. Most of
  these features are cosmetic User Interface improvements or making
  variables writable, such as :

  delete some
  EXIF+GPS meta-data in exported files (for privacy)

  
  set the
  export file resolution from paper size and printing DPI,
set the DPI value right in EXIF,

  
  add/edit
  unique names/titles for modules instances, also within
  styles, 

  
  decompose
  the darkroom history by module AND module controls
(decrease the history granularity),
  add more JPEG exportation options (progressive,
optimized,
subsampling),


  
  apply conditional styles automatically (the same way as the
presets of the modules),
  make styles hierarchical (to clean-up the list),
  allow drawn
  mask edition (size, feathering, opacity) from the masks
list and keyboard input values, 

  
  lock
  position and size of drawn masks for safe panning/zooming,
  EXIF
and IPTC
management/edition requests (date, time, names of lenses without
processor, scans with no/wrong metadata),
  create
  arbitrary collections/catalogs of images (ex : family,
perso, assignments),
  implement
  ESC and RETURN shortcuts in every dialog to cancel and
validate,
  implement a
  coarse/fine tuning option to increment/decrement values
with the mouse wheel
  lots of small GTK glitches with scroll
  bars, lighttable selections
and hovers,
  link exported pictures paths to original RAW files,
  allow to set the UI main color and create user-friendly
theme/template (whitout editing CSS),

  
  etc.

Some are more algorithmically challenging :

  make the RGB
  gains independant in wavelets/non-locals means denoising
module,
  rotate/flip the sampling patch in the spot removal module and
in the freshly merged retouch module,
  add a color correction on A and B channels to fix the
desaturation happening in the local contrast module (laplacian)
with heavy settings,
  display the
  locked AF point on previews
  detecting
  duplicates and similar pictures in database

  
  etc.

  
  plus all the Windows portability issues.

  

And there are still #TODOs in the source code.


Most of these changes are for sure not the most challenging and
  don't make for the sexiest coding party, so I have no trouble
  imagining how little appealing they can be to hobbyist developers,
  but they are nonetheless useful and game changing for
  professionnals who are bound to efficiency constraints. 


I find quite remarkable the dramatic improvements that software
  such as Blender have known in the past decade, and though I get
  why dt developers aren't thrilled by the admin overhead involved
  in a similar fundation to pay full-time developpers, I think the
  above requests will stay idle for some more time if we don't go
  next-level. That would be a shame considering the core is stable
  and sane, and what is needed is mainly cosmetic.


As more and more professional photographers adopt dt in their job
  and are asking for more efficency-driven features, I know that
  some would be happy to fund developpers to smooth all the sharp
  edges listed above. For now, the features that the developpers
  don't need don't stand a chance to appear in the software.


So I found a platform where you could create a bounty for each
  feature request/bug on Redmine, have users/donators fund the
  requests they want in a crowdfunding way, hire freelancers to do
  it, and take care of the payment : https://www.bountysource.com/.
  You can create a dt group, link it to Github,
  open/accept/close/pay the bounties, etc. Actually, it seems that
  darktable has already a project page, but only linked to the
  Github tracker :
  https://www.bountysource.com/teams/darktable/issues. 


Shouldn't we merge Github issues and Redmine bugs/FR, and promote

[darktable-dev] How do you feel about code bounties ?

[Aurélien Pierre]

Hi everyone,

looking at the Redmine feature requests, it seems that a lot of
legitimate requests are left idle, and some have been so for several
years, generating duplicates. Most of these features are cosmetic User
Interface improvements or making variables writable, such as :

  * delete some EXIF+GPS meta-data
 in exported files (for
privacy)
  * set the export file resolution
 from paper size and
printing DPI, set the DPI value right in EXIF,
  * add/edit unique names/titles
 for modules instances,
also within styles ,
  * decompose the darkroom history
by module AND module
controls (decrease the history granularity),
  * add more JPEG exportation options (progressive
, optimized
, subsampling)
,
  * apply conditional styles automatically (the same way as the presets
of the modules),
  * make styles hierarchical (to clean-up the list),
  * allow drawn mask edition
 (size, feathering,
opacity) from the masks list and keyboard input values,
  * lock position and size 
of drawn masks for safe panning/zooming,
  * EXIF


and IPTC


management/edition requests (date, time, names of lenses without
processor, scans with no/wrong metadata),
  * create arbitrary collections/catalogs
 of images (ex : family,
perso, assignments),
  * implement ESC and RETURN
 shortcuts in every
dialog to cancel and validate,
  * implement a coarse/fine tuning
 option to
increment/decrement values with the mouse wheel
  * lots of small GTK glitches with scroll bars

,
lighttable selections 
and hovers ,
  * link exported pictures paths to original RAW files,
  * allow to set the UI main color and create user-friendly
theme/template (whitout editing CSS),
  * etc.

Some are more algorithmically challenging :

  * make the RGB gains independant
 in wavelets/non-locals
means denoising module,
  * rotate/flip the sampling patch in the spot removal module and in the
freshly merged retouch module,
  * add a color correction on A and B channels to fix the desaturation
happening in the local contrast module (laplacian) with heavy settings,
  * display the locked AF point
on previews
  * detecting duplicates and similar pictures
in database
  * etc.
  * plus all the Windows portability issues.

And there are still #TODOs in the source code.

Most of these changes are for sure not the most challenging and don't
make for the sexiest coding party, so I have no trouble imagining how
little appealing they can be to hobbyist developers, but they are
nonetheless useful and game changing for professionnals who are bound to
efficiency constraints.

I find quite remarkable the dramatic improvements that software such as
Blender have known in the past decade, and though I get why dt
developers aren't thrilled by the admin overhead involved in a similar
fundation to pay full-time developpers, I think the above requests will
stay idle for some more time if we don't go next-level. That would be a
shame considering the core is stable and sane, and what is needed is
mainly cosmetic.

As more and more professional photographers adopt dt in their job and
are asking for more efficency-driven features, I know that some would be
happy to fund developpers to smooth all the sharp edges listed above.
For now, the