Anaconda-webui official Fedora chanells for Fedora Linux users

Project Discussion
, , ,
1

I do post in the workstation-wg gnome because I use the Workstation Eddition.

Can we please have an official tag, to address issues/proposals for the new anaconda-webui Installer? From the Fedora Community point of view?

I do find it a bit embarrassing that we do have to use RH infrastructure to report a tool we do test/implement in Fedora Linux. Especially wen the topics get into complaining modes and we do discuss it in the off-topic section. If I do have to ask there again, I just will wake up the negative spirits.

That is why I ask for a direct communication between the fedora community and the community members which work for that project. This way we on ask.fp.o can distinguish between frustration-topics and serious collaboration requests.

In this context I would like also to ask about the existing tags we still do have about anaconda and installer:

anaconda anaconda-gui anaconda-webui installation

How does it look like? Do we still need to distinguish on all this different versions? Or do we soon replace the older once with the webui? If yes, the new one will be soon the only one, please lets clean up the tags.

Bookwar , can you please add the github link on which the actual discussions are going on?
I think that is the repo, right : GitHub - rhinstaller/anaconda-webui: Anaconda Web UI planning and discussions.

For Fedora bugs we still use Fedora Bugzilla https://bugzilla.redhat.com/buglist.cgi?quicksearch=anaconda-webui

The development work happens indeed on GitHub, but we do not have an issue tracker open there, only discussions.

The upstream development work happens also on Jira in https://issues.redhat.com/projects/INSTALLER/issues But is not as easy for community members to find us there indeed. :slight_smile:

2

I think this belongs to the site feedback category, and as suggested in the original topic, this might be discussed involving the anaconda team.

I think the consensus of the ongoing original discussion is that the tags should be merged into installation and anaconda , while it is open if both should be merged into one or kept both. I read some tendency from comments and likes to keep both, given that different audiences might use one of the two, but not link their problem to the very other. Unexperienced users might never have heard of the term anaconda, not being aware its the installer. More experienced users, more deeply embedded in communities, might never link an issue of anaconda to something so generic and so unprecise like installation and thus not search for it (this tag could easily get blurred, as a lot can be put in this category, and if anaconda people subscribe to it, they might even get annoyed by a lot of stuff unrelated).

However, it might have been useful to finalize one discussion, give people a few days to respond and then put forward the outcome when going to the next stage, avoiding to risk to have two inconsistent discussions with different information at once, as this is not an urgent matter or so. However, if you want to put this already now to the next stage, please put this part to the feedback category and involve anaconda.

3

I think it’s worth noting that Anaconda WebUI is not yet the default installer, nor is it the only one for all Fedora variants, see the roadmap at Anaconda WebUI: Progress Update and Roadmap.

4

From the linked Roadmap:

  • Current Status

    • The WebUI was introduced in Fedora 42 Workstation Live ISO as the default installer, supporting Live image installations only. DNF-based installs are not yet supported, this is planned for a future phase.

    • A change proposal for Fedora 43 has been approved, enabling the WebUI by default for all Fedora Spins and KDE.

I’m not sure if the statement that it isn’t the default stands true. If so, then maybe the referenced Roadmap needs to be edited to avoid confusion/ambiguity.

What would constitute being default, if not the fact that it is the default for both (Edit: Desktop) Editions, and all Spins?

5

Anaconda WebUI Roadmap (Shared at Flock 2025)

Here’s a rough view of how we plan to roll out the WebUI across Fedora editions:

Fedora Version Status/Target
Fedora 42 Workstation Live ISO (WebUI available)
Fedora 43 Spins + KDE (approved)
Fedora 44 uBlue, Atomic Desktops, Remote Browser
Fedora 45 Server Edition
After 45 Deprecation of GTK UI

Fedora Server is an official edition, and although Fedora Atomic Desktops are not currently official editions, as far as I know, they are at least considered an important and significant part of the Fedora Project.

2 Likes
6

My request here is not to complain, it is more to create a clear channel between the community and the participants of the Anaconda Team/s ? As I do understand the new installer is a separate project.

If we do talk about the Server edition we generally tag it as server and then we also can distinguish it from the new installer.

@py0xc3 I made a topic here with the involved projects which are or will be involved in the change soon.
The Offtopic request was in first place a rant and not a productive input for changes. I guess we could forget that and go on with the discussion here and let the rants in the off topic section.

After 45 Deprecation of GTK UI

This is soon.

7

One factor that hasn’t been mentioned here - if I’m right, the Anaconda WebUI explicitly asks users to post their feedback on this forum.

So even when we get negative feedback - it is feedback that we solicited from users. Obviously they need to follow the code of conduct, but critical feedback posted here isn’t necessarily an attempt to be hostile.

1 Like
8

You might consider the Anaconda team to be related to changes of Anaconda :classic_smiley:

I referred to the ongoing mod topic. I’m sure the mods ain’t ranting that much :classic_smiley:

But if you insist to keep all that incl. the Discourse tags together in one project discussion topic, ok :wink:

9

Which is not really clear, who of the anaconda involved Fedora users have access to it.

10

You’re right, and

is even earlier.

We can definitely organize a Test Week for Anaconda Web UI as soon as it lands in the Atomic Desktops Rawhide ISO images.

11

Mandatory disclaimer: I am the Product Owner of the Anaconda Installer development team

I think the question to justify the granularity of the tags shouldn’t be - what is the default.

But rather the question is:
do we expect someone to subscribe or search for specifically anaconda-gtk tag and not subscribing to anaconda or anaconda-webui tags. Why would they need that?

Do we have examples of the use cases where we need to filter one from the other?

On behalf of devel team, both anaconda GTK UI and anaconda Web UI are developed by the same people, and share most of the backend. So for development questions, discussions, feedback and planning we would read all or none. (I can not promise that we read everything in the Ask category, that’s quite a lot :slight_smile: )

Of course when bugzilla issues are filed, there is a choice between anaconda and anaconda-webui, but that’s a different story.

12

In first place I made this topic here because we had talked about tags in the Moderation Coordination where I believed not a lot of users which work on anaconda saw the arguments made.

And second Tags are not just for new users or for users which want to select what they want to read in ask, at least for me it is a tool to find content on which I responded find better and faster.

And for me it made sense to distinguish between the everyone-netinstaller and the normal anaconda installer Gtk UI. Now with the new Webui we had several complains because users not found out how to solve tasks the where used to do on the gtk ui of anaconda.

For me it also not is easy to follow up, what is done and what still has been implemented in the new installer. And when we try to deescalate if someone is discharging his anger in the off-topic section then it is really complicated to tell them:

For bugs you have to use Bugzilla , participating on discussions you have to look on Jira (which needs a Redhat account) and the upstream project is on github. Makes it quite difficult having a good relationship with the opensource community which get “forced” to test this new product.

That is a valuable information. So I think we might could try to make the communication between the Fedoraproject and the development which is mostly on Redhat infrastructure better.
I know from my own experiences, working in cooperate business can be stressful, and often a lot of adaption and changes are necessary.

However the work a lot of users make, testing and relating should not been affected about all this what goes on behind. They should have the chance to get clear instructions (how to report, what kind of tests to make if they complain about speed etc.) and also taken seriously when they do make a request on ask.

When even we, which work since long with the Installers, get problems and not have a full overview, how should it be for users which join newly or casually use ask fedora?

Do not tell me, they also do have different mailing lists :smiley:

As the title says, I do wish better official Fedora channels, on which also the Fedora enthusiasts can see, and understand what is going on with the Installers.

I observed a very similar situation when we changed from dnf4 to dnf5, it was quite a challenge to find the correct manual as we had different version on stable and old-stable.

13

I am going to push back on this a little bit.

You are writing as if there is a large disconnect between Anaconda team and Fedora, which we need to fix. In reality though Installer team is one of the most integrated with Fedora development teams, both in terms of communication and development.

The only thing which we don’t do is the end-user support at scale. But it is unreasonable expectation of any development team. And we truly appreciate the help of the Fedora community, “Ask Fedora” folks and everyone else in various chats, forums and local user groups who participate in that.

Yes, of course there are gaps, mistakes, bugs and whatever else. And things can be always improved. For example I need to introduce some routine for GitHub Discussions. And the docs need some love.

We are open to suggestions for such improvements. But whoever comes with the complain that “Anaconda team has suddenly forced something on them” is mistaken, and has not spent any effort to follow the Fedora development in last three years.

Now, back to the topic:

Of course GTK UI and WebUI are different, and there are features missing. We are adding those features to the WebUI. For example a month ago we added the package selection screen, and currently are working on the networking configuration. And there is a way ahead.

This is exactly why we keep the GTK UI available and working.

My point was not to pretend that there is no change. I was talking about purely the forum organization.

We could have tags like anaconda-gtk, anaconda-webui, anaconda-storage, anaconda-kde, anaconda-atomic, anaconda-kickstart and so on. Those are different topics, which can be searched independently. But the more granular you make it, the harder it is to explain and to maintain. So the reason for my question was - to not add the granularity for the sake of granularity, but to have a real use case behind each of them.

And if you have a real use case, here on this forum, to search/read only -webui posts and not -gtk - that’s fine, have a tag then :slight_smile:

14

I didn’t read the recent posts (too much:), but it might be useful to add that the moderation “garbage collection” discussion has already implemented a minor change related to the discussion here:

I assigned anaconda to all topics of #anaconda-webui and #anaconda-gui , and then removed #anaconda-webui and #anaconda-gui

I assigned installation to all topics of #everything-netinstall and #netinstall , and then removed #everything-netinstall and #netinstall

We merged these tags to avoid a “split” of the community’s “information/knowledge exchange” in matters that are related or belong together, while keeping these tags separated seems to not serve a purpose, at least within the scope of Discourse (my impression is that some users just randomly choose any of the related tags → I think it can be overwhelming with the vast possibilities of available tags in this case). However, we kept anaconda and installation separated as we have different audiences, and while some might not even know that the installer is called anaconda, we also have more integrated/experienced users who might never come to the idea of using a tag as generic and broad as installation for anaconda matters :classic_smiley: We are open to alternative suggestions if anyone disagrees of course, but we thought this minor adjustment serves everybody :classic_smiley:

1 Like
15

The information is here … we just have to search about it and when we want to report or discuss we do not have a clear Fedora Chanel here in Discourse. I guess that is the point I try make.

Because a long time, we not used tags. Then we had an excess of tagging everything and even some over-motivated users went after every old topic and filled them up with tags which was causing a notification storm.

Now finally when everything got more calm about the tags, we start to discuss again about them and put “logically” created tags, which where for some users useful tools, together with the explanation: The majority not distinguishes about “installation” and “anaconda”.
This might be true that some not distinguish. It is also a fact, that not really the user is catalogue on a logical way while using tags. The enthusiasts (TL3/4) are mainly doing this work. Asking users what exactly the issue is and repeatedly do the same steps.

I hope @bookwar that you can see my intention is not try to p.. you off. I recognize all the hard work you are doing. But I am not so sure if you also get my point of view?

16

I was just roughly skimming the discussion here, but while I remain neutral, I would like to say one thing about this comment, as I think developers sometimes forget something: following Fedora development (including identifying what takes place where and how things are connected) is a skill, not a decision, and many, even if they wanted to do so, would not be able to do so.

Many types of users end up on Discourse or the main Fedora page (which leads them back to Discourse), and for them, the community takes place here. I think the point ilikelinux wants to make is that this on this place (discourse), where many if not most come together who ain’t able to reach out elsewhere, is not on your list:

I am NOT arguing you should change that or so. I understand that developers cannot tackle all downstream issues, and we need points to translate issues from one audience to the next up to the developers. But even if supporters with experience want to do that, it takes time (from mostly volunteers), because they cannot just open a topic in Project Discussion when they identify an issue that might be worth to be evaluated by the team (e.g., increasing amounts of user reports suggesting a bug or so, or a major issue in the UX design or so that does not make sense to average user [just had that in another Fedora tool]), as anaconda is organized somewhere else (e.g., most major teams have a tag on Fedora’s major Project Discussion platform [I’m aware of the tautological “team” definition I use^^], e.g., workstation wg, atomic-desktops, coreos, infra, engineering, etc → anaconda has not).

This leads to the summary: one needs to be well integrated and well aware of different Fedora channels in order to reach out to anaconda, as knowing “in case of a doubt, Discourse’s project discussion” does not necessarily help.

I am not sure if it makes sense to create a (team followed) tag for anaconda in Project Discussion (I am not talking of ask Fedora where much comes together that is not relevant for the actual developers)? So that at least those who are more aware of how the Fedora community works and when to reach out to developers can reach out quickly and efficiently? This would decrease the entry barrier to reaching out (also in terms of time), as the channels you mention all, again, make it necessary to know about development organization on Fedora in order to find them when something is triggered on any Discourse category (which to find out needs knowledge of development processes, and it takes time if one has not yet had anything to do with anaconda). It would also make the team’s presence to be “felt” by the community, which quickly ends up with this team being assumed to be far away if there is no Discourse presence. My experience is that Project Discussion tags ain’t “overused” → I don’t think the team would risk noteworthy amounts of extra work or so, and also, no one forces them to respond to all opened topics or so.

17

I think we are in a general agreement here.

But we need to discuss some expectations.

Yes, installer doesn’t have a dedicated specific representation here, but that’s the same as any other package. You don’t have a Fedora SIG or a tag for every project component.

Our original assumption is that Fedora Spins SIG, Fedora KDE WG, Fedora Workstation WG are the groups which should help coordinate and aggregate individual bugreports and lead the discussion.

The installation experience of a certain Fedora Live image should be within the responsibility of the group which builds that image. We introduced quite a lot of flexibility in the project so that Edition or Spin owners can tweak the installer functionality. But this also means that Editions and Spins should take some of the responsibility for figuring out how this functionality works and for when this functionality doesn’t work (slitherer being the primary example).

And Fedora Quality team is most likely the right place to discuss everything else. We are working very closely with them.

So the point is - while from the user perspective installer does work as an entry to the rest of the Fedora, installer development team can not be the first line of response for all possible discussions that entry level generates. Ideally we should spread out a little bit and make relevant teams involved in analysis, decision making, refining use cases and requirements.

Now with that being said, if there will be anaconda tag in the Project Discussion category I will subscribe to it and I will ask other team members to do the same. I still can not commit to a specific SLA for the replies here though. Friendly pings on Matrix may help :slight_smile:

2 Likes
18

I generally agree. That’s why I could understand if anaconda would not want to have their tag here. But that people ask about anaconda, “feel it to be absent” (which implies they link something of their experience to it), and that anaconda had created topics here asking for feedback, shows that the relationship differs to other components like (extreme example) systemd or so. Most moderation here is done by TL3 and TL4, of whom many are not deeply intertwined with Fedora development. When something is changed in Anaconda’s UX or so, there is a high chance that the feedback of users ends up here but nowhere else, while only TL3 and TL4 become aware of it: if they would need an hour to identify how to reach out to anaconda, there is a high chance the summary of larger amounts of coherent user feedback gets lost rather than being forwarded anyhow to anaconda. Just an example. QA is definitely the point of contact for many issues related to anaconda, but there is more than QA in the relationship between user & anaconda. Therefore, I appreciate …

that very much and think it is a good opportunity to maximize the likelihood that useful (summaries of) feedback from users about anaconda (apart of QA) can reach out to the team :classic_smiley: As I said, my experience is that the Project Discussion tags are not at risk of overwhelming teams with input, are usually only used by active Fedora contributors and higher trust levels, and …

… a tag does not go along with any obligation to respond to every topic or so. If someone wants an SLA, they have to go to Redhat or SuSE :smiley: If something does not suffice/justify to allocate time for a response, then may it be: there is no right for that. And what is put on Discourse has to be considered not time critical anyway. If something is completely offtopic, flag it, and a mod will take care of it. But who knows, maybe here and there useful information is passed to the team that otherwise might be lost :smiley:

@kevin @mattdm @jflory7 Sorry for bothering, but it seems moderators can only add tags in Ask.Fedora, but not in Project Discussion. Could one of you add a tag for anaconda in Project Discussion? I presume #anaconda-team might be more appropriate than SIG or WG (?).

1 Like
19

A Service Level Agreement (SLA) is not existent in Fedora Linux. We always try to emphasize this clearly, when someone comes with expectations to be treated as a client. We are not selling services, the majority of the enthusiasts which help here do this on their free time or while they work to solve own issues. And so when they see something they can help, they simply give some input to the User which tries to solve an issue.

Exactly. I also do have my limits in giving to the Fedora Project. I mainly respond of Notifications I do get in Discourse and have a look what is new when time permits. Even if I would like to use more Matrix I still not feel comfortable with this tool, and I do not have a real workflow to use it.

1 Like