Sure, I can do that, @ilikelinux
This is a very big assumption you make for all user groups and audiences of Fedora.
If I get it right, you expect there are just average beginners with average use cases, and kernel developers who can do everything in the command line themselves, and the two groups form a dichotomy.
I can find everything when formulating a corresponding query at my preferred search engine. That does not make it representative. I can be, but does not have to be. Not the data we should rely on in decision-making imho.
Sure, if they don’t ask about partitioning, no reason to make it a topic. I think the discussion is more about those who ask about it 
I don’t say its wrong, but do you have data confirming these very specific arguments? And is there a reason to assume its representative?
This assumption is totally new to me, and I would indeed be interested to read more, so real curiosity here But I admit I also have seen many surveys of Fedora that were designed with little science but with many potentially-false presumptions in place, leading them to be tautologies that could only confirm these presumptions. So I became a little careful with trusting data about user preferences without reviewing the origins and limitations.
I am not sure where you read that. Because that is not what I was talking about. And searching for docs does not turn you into a kernel developer.
You shared your personal experience with starting with Linux.
I tried to explain that the experience of starting with Linux is different these days. Partially because of the work we did in the installer WebUI.
Getting familiar with partitioning is not necessary for a Linux user anymore. It can happen, but it is not required. And it is a good thing. We are making Linux more accessible. People can get familiar with the system and the project at their own pace, when they feel ready to do it.
But then you are saying - what if a user doesn’t want a default because they are curious about non-default system features. But at the same time they are not curios enough to be even asked to read the user documentation. And we are not talking about sending patches to a kernel mailing list level of involvement here. But about searching the answer to a question and getting it in the official user facing doc.
And well, let’s be realistic, there are always going to be limits for how much we can support such requests. With great power actually comes the responsibility to learn how to use it, and all that.
1 Like
Ah, I think I misinterpreted the context in which you placed your argument. Sorry
1 Like
If y’all need data from our “end users” (and not our contributors who have no idea what “new user perspective” could even be) I’m happy to create such polls. Give questions / answers what you would like to see.
I’d like to balance the discussion and say that I consider the Anaconda Web UI a step forward, irrespective of the features (yet) missing.
We tend to forget that the old GTK-based Anaconda had quite a few counter-intuitive design features, among other issues, but users got so accustomed to the interface they didn’t notice them anymore.
2 Likes
I wonder if it is useful to once plan, prepare and conduct a real survey, maybe less for the installer in specific, but the long term strategy to increase contributors, which might contain questions about installer expectation (but carefully designed questions that answer OUR questions without provoking a user’s shame instincts and without being explicit to the participants, control questions etc)
I mean not the average surveys we did in the past, I mean something that is planned more carefully and as far as possible with rationalizing assumptions, limitations, etc. in short, scientific as far as possible, and trying to also deploy it to different groups / audiences.
I doubt that a Discord channel can be representative, but I think it could reflect one audience of Fedora, and it likely is a user-centered audience (which already introduces the first assumptions). One can ask users where they get help and where they got the link, but also use different links. That can help to link responses to specific groups but also identify groups (or split what was assumed to be one group).
The two Devel “channels” could be another two. “Ask” needs to be considered very carefully. There are several channels that can be used and isolated, to see how homogeneous they are within but also among each other, and where things go. And what preferences can be seen.
I have seen so many surveys that provoked corrupted results, and so many derivations and plans based on such outcomes…
But that would be an effort, and I think it would need a Council-level to get support and motivate people to do it in the very channels. But the considerations to design and document would already start at when to put it where and how. I think what I mentioned in this post is 1% of the considerations even before such a real survey would start.
I think we had the people who are qualified to jointly get something like that done, but not sure if the efforts go beyond what they can create / maintain in terms of time investment… And the issues would start already in the feasibility stage (at which everything can already break) 
But the pure thought might be hereby spread… 
dreaming should be allowed 
As a person pushing for Fedora Annual Contributor Survey I am actually all for the idea.
We have a current list of the Survey questions in Making sure you're not a bot! If you have any ideas how to extend it, to make it more helpful for discussions and decision making, please just send the PRs to that doc.
Some sort of user testing or surveying specific to the installer might also be a good idea, but 1) it is quite time and resource consuming, and 2) we need to prioritize it against other features in progress.
As I mentioned, partial kickstart support (=the ability to pre-fill some of the installation options from kickstart snippets) currently wins the focus. It is a huge thing, both in terms of backend architecture and the applications across different use cases. Together with remote installation it opens the UX paths which are not available now. And I believe it can significantly change our default mode of operation.
1 Like
I have to think a little about it and keep you updated 
I will review this in the next days and see if I can come up with something useful
Just my two cents here.
I’ve been using Fedora since version 33; previously I used Debian, Ubuntu, and also tried openSUSE, Arch and its derivatives.
That said, I have to compliment the developers of “anaconda-webui” because they have made the installer simple for the average user and powerful for those who want to customize their installation with regard to partitioning. The advanced partitioning menu is a bit hidden, but that’s fine — an experienced user does their research and knows where to find it and what to do.
Personally, I customize the installation because I prefer not to have a separate boot partition, but only the EFI partition and Btrfs with modified subvolumes — and whether you prefer Btrfs, XFS, ext4, or anything else, this is very straightforward with the current installer. If I really have to find something to complain about, it’s that I cannot choose mount options at the time of advanced partitioning.
I also tested it as an average user — or simply someone who just wants their computer ready to work right away — who doesn’t care about or doesn’t know what’s best for partitioning (ext4? Btrfs? XFS?..). The step-by-step procedure turned out to be intuitive and straightforward, greatly speeding up and simplifying the installation process compared to the previous one, and a major UI/UX improvement. Furthermore, it is the only installer (again, kudos to the developers) that, in the case of a RE-Installation, allows you to preserve the user’s home directory (leveraging subvolumes) and perform a clean install without having to back up and restore the data in the user’s home.
In conclusion, I am strongly in favour of the current state, where by default there is a step-by-step choice that is easy and straightforward to use. In fact, thanks to the simplified installer, I am now more inclined to recommend Fedora to new users as a first approach to the Linux world.
3 Likes
That should really include the type and size. At the moment it’s useless for the user, they still don’t know how to create them.
Precisely. I’ve been taking care of Fedora reddit and discord since 2016, without any real help from the “official project channels” - always ignored despite representing the end user community. I wish that could change, alas I don’t think that we’re “there” yet. If anything, the current landscape of privacy violations by governments and corporations made things even worse when it comes to “3rd party platforms” regardless of how active they are.
See, now that’s excluding the End User by design again… Contributors are not end users. An end user is someone who relatively freshly converted from being a non-open-source user, windows/mac user, to being a linux user. Someone who may or may not convert into being a contributor some day - if they feel welcome, if they feel heard, if their journey isn’t full of roadblocks, etc…
Where is the mid level user though? This is a user-story (a real one):
Mid level user - the one who knows that they want a different partition scheme, but don’t know how to set up boot. For example my partner in my own house. Moved from Windows to Linux 10 months ago. (Re)installed Fedora on tens of devices, a few hundred times, different DE’s, arches, you name it. Now they have a home lab with countless services, containers,.. several retro emulation stations, handhelds, etc… They can fix almost anything, run niche DE, but they can’t create a boot/efi partition. (And I still help with the occasional kernel issue, dmesg type of debugging, etc.) Why? There is no valid/accurate/complete documentation (until PR that was created based on this thread by another Discord user who picked it up as an “easy contribution” ticket.) That’s what I call a mid level user. Anyway, refer to the first paragraph of this message.
This was never about the editor being hidden in the hamburger menu. This was about the fact that the editor is incomplete in several different ways. Lacks functionality that the old one had, and does not make up for it in communication / documentation.
I get your feelings. You’re a valuable contributor and your opinions are valid.
3 posts were split to a new topic: Issue when trying to install F44 Beta with Anaconda Web-UI
@x3mboy While I don’t appreciate some of your formulations, I understand some of your frustration.
I am myself not convinced if the current state of web-ui can deter/alienate some user groups.
But keep in mind that we lack factual data, both sides assume a lot, and we have as many “it’s OK and the right direction” feedback as “get rid of it!” feedback. Keep in mind that the devel mailing list post (which was meant neutral to accumulate data/information and not to go into any particular direction) also did not receive a response, in a well reviewed mailing list of ours → that implies also a type of “I don’t consider this worth discussed”-response.
In the end, we don’t know, and in case of a doubt, this is a do-cracy, and the team doing the work decides which assumption they assume to be most applicable if there is no proven-applicable data. Above all, there is FESCo, and with regards to your assumption this is Red Hat, this was reviewed and accepted also by non-RH people: I don’t see data confirming this is a RH issue. I would not add FESCo’s reasoning & considerations of back then to this discussion though. Neal made a point about it, and everyone can review discussions of the past.
I consider the extremes in the feedbacks noteworthy, here and in other topics too. But I spare for now more assumptions of why, except a reference that this might be at least partially also communications problem. But it can be questioned if we can solve this quickly in the here and now.
In the end, the only “guaranteed useful” thing is representative data (beyond web-ui, for the wider context), and getting that is not a straightforward task. I try to think about it and get in touch with those who might help if I come to the conclusion something is feasible. But that surely will take its time, if it is feasible at all…
But the one thing we should agree on is, at least, that there is no representative data available, for neither argument. So any assumption of “I am right and the others not”, on both sides, is not applicable, and thus not constructive (especially when going along with cursing others or the work they do)
@bookwar has someone of your team subscribed to anaconda in the ask.category? With regards to the posts I just moved from here into a separate topic (I saw you’re already active there, thanks for taking care), I saw the anaconda tag is actively used.
I think it was already pointed out, many users might arrive here and provide data who would never end up in bugzilla or pass the (for average users potentially intimidating) path to a submitted bug report.
I am aware you cannot tackle all these cases (that’s not what I am asking for). But I could imagine the likelihood that a new bug gets documented here is much higher than that it gets documented in bugzilla. So having a subscription to the tag and occasionally skim through the posts or at least the topics* might be valuable from an anaconda-team perspective?
If something is new, worth for users to be considered (potentially type of “common issue” or so), we might also find ways to just mark it quickly with some additional tag or so (by your team, not the community) to be available automatically at some place in a consolidated manner to which others can be linked. With regards to the earlier-discussed idea of having a link in anaconda forwarding users to “common issues” that they might experience and that are already known, it might be useful to have both your jira and a place like that here if the jira proves to be not maintainable on the long term and/or to be not always up to date or so. Just a thought
* subscriptions can be set to both, all new posts, or only new topics of a category and/or tag → e.g., just send an email for every new topic with its initial topic-post when marked with anaconda, but no responses of the topics