We (the docs maintainers) already requested that and it was rejected by devs.
That’ll just delay features, which will not make the devs happy.
Yes there is already a system in place, it works relatively well, the work just needs to be done.
We don’t have to please everyone, as the module panel layout is already customizable, and this change wouldn’t overwrite user settings.
It just needs to be opinionated.
Darktable doesn’t have any items that need to be configured by the user before it can be used, so a wizard isn’t really needed. Defaults are a pretty good way to emphasise one option out of several, especially when a new user lacks the knowledge to make a choice. And it would require maintenance.
As for forcing devs to write “comprehensive, high quality documentation”, that means you’ll be losing devs, as documentation writing is a different skill than coding.
You‘re comparing a software, where a company with paid developers is owner of the tool and have economic interests in the tools with a free tool which development is driven by enthusiasts spending their spare time to improve a tool they use theirself.
darktable is a tool that is shared, not a tool developed to gain market shares.
So a broader user base is just beneficial, if these support the development by spending time to improve, writing documentation, do support via GitHub, pixels.us etc.pp. It’s about sharing, not aquiring marketshare…
User, who aren’t willed to learn about the basic ideas behind darktable and just requests it to be a better free Lightroom, aren’t helpful to further drive improvement.
darktable is highly configurable but you need to know, what all these options are doing. So presenting a wizard to those, who never heard about tonemapping or all those options won’t have a change to apply proper settings. So the approach to have a quite reasonable basic setting, partially done by evaluating the technical capabilities of the system and let user tweak when they know what they are doing, is the better way.
So instead of demanding changes, new wizards, simpler tools that effort is better spent in
ask the developer of filmic, and he will explain why filmic is preferred, …
The tonemappers are made from different developers having different requirements. There’s no ‚if this than that’ approach - it‘s about learning the strength and weaknesses in different intentions of editing.
The default is not made based on artistic reasons but as a answer to the question: what’s appropriate as a general starting point
Hello,
I really like your concept of sharing. It’s a great positioning for Darktable. A free (gratis) product has no value.
To get back to the subject of the post, it wouldn’t be a bad idea to create a popup that launches on first startup to communicate Darktable’s positioning and identity, as you did in your reply.
And why not add a link to the documentation in this popup?
Greetings from Luberon,
Christian
At some point we were all more or less “noise”. 
This is part of the learning process: to start supporting, one must learn first, so asking sometimes stupid questions is part of this process …
There is a fairly detailed discussion about doc changes here: A plea for help writing the docs - #22 by hatsnp
And the link below gives a list of darktable issues marked as needing documentation changes (but note that some will already have doc PRs waiting for review - you can scroll down a particular darktable issue to see if it is linked to a dtdoc PR):
Asking questions is one thing: if the devs and experienced users were annoyed by questions, they wouldn’t be here…
What gets unpleasant is all the suggestions on how to “improve” darktable, with different levels of detail (often not even enough to understand what the poster wants), and some showing very little thought about why things are as they are.
Note that I’m not contributing to darktable;, the same thing happens everywhere (more’s the pity).
Wizard? Here it is…
an introduction to darktable’s workflow
On-screen starting point for beginners?
The darktable has some introductory text on it (which I would like to be able to turn off!)
The darkroom has the Quick Access tab, which is a great place for beginners to start. Some things are not there, which is an introduction to this being software to explore and discover rather than be guided through.
One of the reasons I am a dt user is that I found the rawtherapee documentation hard to understand and the dt manual much easier. There is only a limited amount of the dt manual that feels like one has to be a mathematician and colour scientist.
I was not only a dartable dumbo (and still am), but I was even completely new to raw processing. I’m finding my way. And I think anyone can. I do have some techie in my background, but zero maths (they even threw me out of the class!): I am not the brightest kid here, by a long way. If I can manage it…
Especially since Sigmoid-default almost did away with the first barrier to entering the world of raw: the dull picture with little saturation or contrast. It is not that hard to get started with dt. And the very fact that someone is using raw files at all suggests that they may, techie-wise, be beyond needing a paperclip telling them that, having increased the exposure, perhaps they might like to look at the contrast and saturation?
I guess I come over as sounding rather cynical. I too found it hard to take the first steps with raw. I am soon out of my depth with dt: but I moved on from paddling in the quick-access tab (which is still useful sometimes) but I’m still wearing a rubber ring. And I know that, even when I take that off, there will always be deeper stuff in dt, as and when I feel the need.
See… I was going to suggest a link to the manual in that text on the blank lighttable screen and… hey, it is there already. Embarrassment avoided 
Make it more prominent? Add a direct link to the workflow section? And the dt 5 faqs?
Maybe add a link to an approved video? But then, who would chose it!
I still, occasionally, watch a dt-for-beginners video. And I’ve seen one or two that were really bad! But hey, this is the internet. And… not all the books in the bookshop are good ones.
My bottom line: no we don’t need a wizard.
I think this discussion skips an important point of Tantacrul’s video : user testing. You need know what new users are struggling with in the first place to make informed designed decisions.
I would post something like this (quick draft, maybe on r/photography, r/opensource, … ?) :
Looking for user to test darktable
If you :
- Have used raw photo editing software before
- Never used darktable or haven't used it in the past 5 years
Then could you try to :
- Download and install darktable
- Open an image
- Crop it
- Adjust white balance, exposure, contrast and saturation
- Raise the shadows
- Export it
For each step write a short note stating if you managed to do it, if you had any issues, struggles, or if it was easy, etc.
Thanks for reminding where this information exists. I will try and have another go at contributing to the documentation. Understanding the required or preferred method is something I need to learn but I will give it a go.
Please remember, developers are human too. They are not chasing technical achievements in a vacuum: they know that people are going to use it.
And, frankly, I don’t think they want to waste their time on corporate-style feedback questionnaires.
One thing I hate: I withdraw money from an atm: the bank wants to know how my experience was.
Our developers are not locked in cubicle bubbles, and they do interact with us users, old and new, right here on the forum.
you just used the exposure tab: how was your experience? Would you recommend it to others?
If this seems rude, well… it might be, I suppose. It really isn’t personal. It’s just that I have an allergy to certain cultural forms and norms that are spawned by Microsoft and corporates.
I recommend watching this short section of Tantacrul talk on Inkscape user testing (which has a configuration wizard so it’s particularly relevant here) :
Sorry, I don’t think I was comparing both software. As I said, it was just an idea I saw in the video and got myself wondering if it would be helpful in Darktable. Not in a way to make it easier or more approachable at the expense of what makes darktable darktable, but on the contrary, how to make newcomers understand darktable’s paradigm faster. I do not at all think that darktable is, or should be, a free alternative to commercial software. And I much prefer to use and support open source, community-driven software whenever I can. I say all this just to make more clear the intention behind my suggestion.
A lot of people think that the idea has no value, or at best that its not as simple as I thought first. That’s ok, I see everyone’s point now. As a simple user I don’t have a strong opinion on it, and am ready to accept more knowledgeable feedback. I’m sorry this came across for some a criticism of how the development of darktable works. It wasn’t my intention at all.
I’m one of those users. I found RT a better fit than DT because of its functionality and manageable learning curve. DT seemed too modular and hard to grasp, even after using Lightroom for eight years. I stuck with RT because it fits my workflow.
That might perhaps be “because of using Lightroom for eight years”: there’s a big difference in the way the two programs work, and what you get as an initial impression of the image. That doesn’t mean one is better, but habits you learned with Lightroom may actually work against you in darktable…
At least that’s more or less my experience when starting in darktable: I had used several other editors, and had to spend time getting familiar with the way darktable works. And that’s something wizards and setup guides won’t change, darktable just worked “out of the box”.
I actually downloaded DT and tried it again a summer or two ago, and still couldn’t find my way around the UI very well. Maybe by then I’d been too used to RT, lol. But, it’s obviously very useful software as it looks like many (most?) of the forum members who shoot RAW are DT users.
Any problems, just ask, I’m sure someone will know the answer. There is sometimes quite a long delay in getting doc PRs reviewed (there seems to be one reviewer, with limited time for this), so be patient.
It didn’t come across that way and I think we all understand the sentiment behind it. It is, however, feedback we get quite a bit of.
That’s too bad. Unless you have a pool of dedicated docs editors there is no other scalable way of ensuring that features are properly and timely documented.
+100 to this. Streamlining requires a vision and the ability to enforce it. Unfortunately, in an open source, voluntary-based software development process it is very difficult to converge on a shared direction.
With streamlining I don’t mean that modules and configuration options should be remove. I totally agree that DTs flexibility is one of its strengths and distinguishing features, but the complexity does not need to be in the face of each and every user.
I don’t mean to be harsh, but in more then 25 years of sw-eng experience both in the academia and in the industry I heard this argument very many times and it does not hold water.
It is a logical fallacy and the conclusion does not follow from the premise.That a dev is better at coding than they are at documenting does not mean that they should not try and do their best. The truth is that most devs don’t want to bother writing docs, and when it comes to software development who writes the code has more leverage, so they get away without it. Unfortunately for them, and for us, this is the best way to create technical debt and, as we are discussing here, a great piece of software (which DT is) with an unnecessarily steep learning curve.
Thanks for the pointer!