Obviously it’s a tricky business to get the balance between at one end people developing whatever they want (sometimes brilliant, sometimes pants) as compared at the other end to a rigid commercial-style programme board.
How about the devs making more use of the forum? Would it not be good to get feedback on proposed changes before proceeding very far? They don’t have to do just what the forum says at the end of the day.
And also use the forum to find out how people are using dt. Aurelien went on about the number of preferences, for example. Do the devs have any feel for how many people use some of these? They could launch some questionnaires in the forum to increase understanding of general usage.
anon41087856 == AurelienPierre is that correct syntax?!
I can’t agree more with this sentiment. That said, I do see the reason for Aurelien’s frustration, and for his fork. His criticism in terms of usability is completely valid in my opinion, despite his tone or choice of words. The problem in my eyes is that he didn’t give other devs a gracious way to agree with him without losing face. He is probably right, and the issues he is pointing towards are probably wrong, but nobody likes to be told in public that they are stupid.
It might be self evident, but it is also important to realize that this forum is not a homogenous group of people. In particular we are not all North American. French people (or Spaniards like myself) tend to be more direct and to swear a lot more than Americans, and often our tone and words come across a bit blunt or aggressive in English. I am not trying to argue that his tone is the appropriate one for an online forum or discussion, just pointing that there is cultural bias at play as well. To me it wasn’t as big a deal as for some.
We should also bear in mind that he is the developer of filmic, color calibration, color balance rgb, diffusse or sharpen, and the upcoming color equalizer. Basically darktable’s most important bits. When someone like him basically gets fed up with the multitude of options (which is real), the features that rely on other libraries that are hit or miss (like the tethering view), etc. and decides to mantain his own fork, with the amount of work that involves, should give everyone a moment of pause. What I also appreciate is that he doesn’t just rage quit and call everyone names. He doubles down, does the work he thinks is right, and explains thoroughly why he is doing so.
I agree that we should strive for a civil discussion in these forums, and our mods do a good job in that department. In this case, though, I think the most important issue is not how many times Aurelien has used the f-bomb.
That’s what pull requests are for and github is the place for those conversations IMO. Everyone here is free to sign up for a github account and comment on changes before they are merged (indeed some of these issues could have been resolved before merging if more people had taken an interest while they were being developed). I’m not convinced that spreading those discussions onto the forums is necessarily the best way to go, but of course anyone is also free to start a discussion here if they want.
One of the challenges of project maintenance is reconciling lots of differing opinions on a change. More opinions can be a good thing but at the same time, “analysis paralysis” is also a thing and at some point someone has to make a decision (and probably annoy people in the process). And again, while I may not always agree with the result, the current darktable maintainer does always take comments into account before deciding to merge a new change.
The problem with having everyone (and their uncle) sign up to github, and promote changes for darktable, is you could have people suggesting stuff like or “an online store front in darktable where people can download presets”.
Too may cooks spoil the broth, as the saying goes?
If you encourage everyone to discuss upcoming changes on github, don’t you risk too much noise for what is originally a channel for those directly involved in development? I’m not sure e.g. the discussions about the sigmoid “module” as an alternative to filmic would have been very useful on github. Discussion about the technical side of proposed changes risk to get lost in that case.
So having discussions about changes might be better here (or rather in the relevant section under software) when you want opinions not directly related to the implementation itself.
You’re both right of course about too much noise on github, but in the end, darktable is an open source project and that implies a certain amount of freedom for users to express their opinions. There are no technical restrictions on who can raise issues or comment on the github project but I would hope people are able to show restraint and only comment where they think they can positively contribute to the discussion.
There’s no problem with people discussing upcoming changes on these forums (and people often do so) but I wouldn’t necessarily expect the developers to initiate those discussions or participate in them. I expect some of the developers don’t even have a pixls account.
I also don’t think github is the best place. Mainly because I think there would be too little engagement with most users. Also there are quite a lot of pull requests and some are quite technical, e.g. Support compiling for RISC-V 64 architecture. I think user input is more valuable for the more visible / gui / main-function changes.
I think it’s too late at this point. The dev has done 80? 95? percent of the design AND programming by the time a merge into Master is requested?
I agree, I think users could take more interest (if only out of self-interest!)
It should never be too late to rethink a design. We don’t run to schedules in FOSS so we have the freedom to spend time and consider changes before they are merged and to reconsider them afterwards (and even revert if necessary).
For larger pieces of development, I would expect a developer to raise an issue (feature request) against the project for discussion, before submitting code. An alternative is to submit a WIP request early in the coding process so people can view some early stages of the design. The later you ask for contributions the more rewrite you might have to do to get code merged.
If you want to know what ideas people have had (and might be working on code for) you should review the list of issues.
For this specific example, the PR11066 was open on 05FEB. It had a lot of comments and work by multiple folks until it was merged 17APR (yes 2.5months of development). I tried it after it was merged and at first I was lost. I could not figure out how to filter based on stars until I read that you can swipe. It took me some time to adjust and get used to it. Now I like and prefer it.
It wasnt until 3 weeks after it being on master (07May) that it became an “issue”. There was hardly any positive feedback of how to make it better, eg add this or that. No alternative other than trash it. But the developer still made improvements to move forward.
But nothing is final. We can still provide more feedback and continue to make it better for 4.2 and beyond.
I don’t understand this attitude that once a feature is merged, the only options are to add to or alter it in an evolutionary manner. Sometimes even the best ideas just don’t work out, in which case reversion must be a valid option. Calling such a suggestion “unconstructive” or “negative” is just a way to dismiss it out-of-hand without consideration.
I agree with what Aurelien has said in the past, that the processing pipeline is at feature completion now and the design of the processing pipeline has been stretched about as far as it can go.
We can present the same-ish operations in a new UI (like the new Color Zones that is coming), but I don’t think it needs any major new processing modules.
It’ll carry on as long as people want to work on it, and there are quite a few contributors right now.
Yes, he had a lot of knowledge. But if he doesn’t want to be here, nobody is forcing him to stay.
I think we can call this event a “major crisis” for DT. I suggest 4.0 be postponed till we have a clear view on how to address Aurelian’s points : should the collection filter be brought back as before for example. Honestly, there is a chance that many dev will join Aurelian’ fork , because most of his points make sense in my opinion.
I disagree, forks happen all the time in FOSS. Its part of the culture.
That’s not going to happen, the release is about a week away. If you followed on github, the discission happened already. There is room for more, but the release will happen.
I don’t know about that given the ways he’s spoken about others in the project.
I agree with many of his points as well, and I voiced my opinion on github too. Quite a few people didn’t agree and the change was mostly left intact. Unfortunately Aurelian has a habit of going scorched earth with his comments, which I don’t think is right way to do it.
But I’m not sure that Github is the best place to discuss and address the large scale, long term direction that darktable may be headed. The migration from to scene referred and how to decide which display referred modules should stay, and workflow approaches to make DT more friendly to professionals come to mind, and I’m sure there are many others.
Those are more along the lines of big picture, strategic objectives that don’t lend themselves to discrete issues, although implementation could certainly be broken down into into change requests that would be opened, tracked, tested and closed. It seems to me that the forum is a much better place to have those sorts of discussions, but it also raises the question of how to achieve the consensus and move forward with everyone on the same page. Which I think is a large part of what Aurelien was complaining about.
