I think there is no “by mistake”. Always mark a ticket for the meeting if you are unsure. If there is not much to discuss about a ticket, it will be solved in a few seconds anyway, so it will not cause harm. This is better than have a relevant ticket unconsidered. Also, if it is marked for the meeting, it may be already facilitate some “immediate discussion” in discourse in the “Docs meeting agenda: XXXX-XX-XX” thread, as we do it at the moment here. @pboy maybe has a better feeling with what makes most sense atm, but I would stick with “mark everything you could imagine to be relevant for the meeting”. A common “informal average” will develop over time about what tends to be marked.
It is not explicitly mentioned, but you can always open a topic about tickets, to raise some attention and/or facilitate discussions. I like that idea, indeed: if anyone perceives that the number of “meeting” tickets could bypass the capabilities of one meeting or if some need more detailed/time-critical consideration, just open a topic → this cannot create harm but only contribute to solving issues.
As an after-thought, what tripped me over about updating a guide or not could be the word “unmaintained”. I guess the term has ubiquitous meaning among package developers and maintainers - if a package is not maintained, it will be flagged as orphaned and removed from the next release. Does it not?
What I could offer to my best intention is;
Get feedback from users
Assess possible simplification in process or wording with feedback received
Being unmaintained leads to the package being orphaned, because it no
longer has a maintainer, which means it no longer receives updates (but
it still can get new builds). No updates can lead at some point to
security and stability issues (or that builds no longer work for some
reasons). However, in some circumstances, a package might be kept even
if it is not maintained.
So I used the term in the correct meaning: a GitLab guide to receive no
longer updates or adjustments to changing circumstances, which can break
its content once further changes are applied by GitLab, or cause other
issues that need maintenance.
But we found already out that we had a misunderstanding about what we
interpreted from the “waiting” for further GitLab changes before going
ahead (the comment we were talking about yesterday). I interpreted the
guide being unmaintained from that point on until there is a decision if
we can and want to maintain it again, or if we cannot and thus get rid
of it at all.
So I meant WHAT the term “unmaintained” implies, but THAT it applies was
We have some tickets about design issues. I remember the invisible burger menu on smartphone screen, we wanted to have an abstract paragraph, or we wanted to graphically emphasize the issue and the edit button in the top bar. But there are some more.
You are right, it’s Monday, we should start to compose a list otherwise we can’t discuss it on Wednesday.
I love a challenge beyond my comfort zone. But in this occasion I won’t be able to contribute to Docs design work. I think we need more alignment and discussions with relevant teams prior to weekly meeting. With that in mind, we could avoid screaming into the void.
i got an impression that a previous thread titled Docs design work is rather evolved around aesthetics over form.
I was hoping for design principles associated with user experience, usability, and a11y.
At the moment, as a first step, I think we have to focus on what we have, the current design of the home page. I’m not aware of any planning to rework the current design, nor do I see any resources. But that may change in the near future, because the Fedora Website revamp project may continue with the next step.
And before we discuss design, I think we should collect a list of known design issues and make a plan how to make progress.
Urgent usability issues like the dark-mode styling are already in progress. I recall thin scrolling bar, too. I just need to limit my time to what I can do best rather than piling up a list of issues during meeting.