For the third or fourth time, I see a pipeline error in the user documentation:
Please, could someone take care of it and fix the problem?
It feels like we have to deal more with the tool than we can devote ourselves to the essential task of maintaining content. That’s just annoying.
Generally, this should not cause trouble, but you are right that it should be avoided to take failed pipelines for granted. It could be discussed if it makes sense to disable code_quality (which is the one that failed) at all.
I am not an expert in the GitLab pipelines, but I think you need to talk to someone who is owner in this list: Members · fedora / Fedora Docs / Docs Website / Fedora Docs pages · GitLab (I guess most of them are not watching the #docs category here).
However, when reviewing who has owner rights, I assume that most will not know as well how to handle that. I think it is @darknao and @ryanlerch who manage such things, but I am not sure.
Issue ticket opened asking to check CI script.
[Update 12 Jun 2023 UTC 10:43]
issue closed by this commit
A post was split to a new topic: Infra collaboration issues
Among some off-topic issues on design,
one is opened by you: Improvement of visibility of the contribution icons on docs pages (#6) · Issues · fedora / Fedora Docs / Docs Website / Fedora Doc UI · GitLab
Could you tell me what other issue ticket in Docs UI repo needs priority to resolve?
Accessibility and usability issues - PRIORITY
Issue board in Docs UI repo: 6 open issues
Issue board in Docs pages repo: 1 open issue
To put discussion in a good light with other contributors, I think your reply needs to be split as a separate thread. The last thing I want to see is screaming into the void.
@py0xc3 could you do me a favor to open a new thread if you don’t mind? Thanks in advance.
I think we should decide about priority in a meeting. From my perspective, #7 (scrollbar) and #6 (search results on mobile) are the most urgent ones.
I thought the vale / CI issue was resolved? Today I got this issue again for every commit (e.g. here). It’s annoying.
With regards to [1], have you got in touch with a related/responsible team or someone who administrates the pipelines?
Just creating tickets within Docs and waiting until darknao scrolls through them and casually / informally solves issues is not a good long term solution imho. This should not be expected, especially since he has formally left.
Don’t shoot the messenger (me). My attention span here is poor during summer holiday. Will switch off completely from Sunday 25 june.
Please check this feedback on issue ticket. Vale rules need to be synced manually in CI script, which is not good for contributor experience if someone finds out vale rule is out of date and asks it to be fixed every time.
@py0xc3 the vale.ini file in CI script is applied to Fedora Docs pages repo and contributor guides by @darknao. I wasn’t certain if one need to reach out to who in infra or web team.
No, not yet. It’s just a reminder that this causes more trouble than it helps at the moment. Hank and I agreed to deactivate it for the time being. I’ll contact darknao next week together with some other issues we need to get solved. As soon as we create articles which are in GitLab repos, it may be more useful, and we need to resolve it then.
I don’t shoot anyone 
As we discussed previously, we should simplify our procedures and, given our current resources, limit ourselves to what we actually use. When we started with vale, the current direction was not yet foreseeable.
And darknao has not left but has to cut back at the moment.
Maybe I got something wrong, but my perception was that darknao has too much on his to do list so that he can no longer focus on Docs. I do not understand the advantage in keeping these things on his shoulders while Docs keeps isolating from other teams when it comes to actual contributions/work/problem-solving, or what to achieve when reminding within docs. Going beyond Docs boundaries facilitates problem solving (likely faster than this way), interactions and knowledge transfer/gathering, and maybe also leads to new innovations/ideas, or at least flattens the communication channels (which by default decreases the amount of work and of people on whom problem solving depends on). I have to admit that I also missed a little this “major community experience” and its advantageous in Docs.
My suggestion is, when such a problem appears, get through the community resources and channels and check out who can help/is responsible and get in touch. If you are unsure, just get in touch with whoever seems closest. This on itself leads to learn a lot of the community and how to get things done and problems solved quickly and efficiently. It would have been indeed interesting which of the two teams is responsible for such things and what thoughts/ideas they have and had. New ties are always a facilitator for improvements, exchange, innovation and ideas 
Just some thoughts.
He is nevertheless a member of the Docs team and the board (he wants to keep it that way) and will take care of design or technical issues. But he can no longer attend meetings continuously.
Unreserved agreed to. Would you like to take care of organizing and pursuing those communication processes? Kind of “Docs team communication officer”? You could take over from pbokoc the Docs representative seat in the Mindshare committee (of course, we would have to ask him). The next 3 most urgent tasks would be, according to my memory:
There are about 3 - 5 additional outstanding actions I currently don’t remember out of my head. But I suppose those are less urgent.
Maybe I misunderstood his points in the April 26 meeting. I still read the same, but there is indeed some space for interpretation (I just re-skimmed them since I was a little confused of the recent posts). I still didn’t understand the need for triggering flows through him when he has a lack of time while you want to have things solved quickly/efficiently. However, …
… I think I now start to get your understanding of “community”. But I cannot agree to it. The community should not be a burden or a task that has to be conducted before you can focus on other issues, or something that has to be allocated to someone to “free” others from the “obligation”. The opposite is the case: the community solves problems, and it does that very effectively and efficiently, which is why this concept is so successful in the global competition.
You might reconsider how many posts and time have been lost in these two topics, and how much time it would have needed to get in touch with the two teams. I’m sure this would have needed less time (and less people), and I could imagine that it would have led to much more information about the reasons for the current condition, and thus improved the decision-making about how to proceed, but maybe also led to more potential solutions if all “needs” and “capabilities” would have come together. At the same time, this would have strengthened both team’s understanding of each other’s needs/capabilities, which can be a strong facilitator for future improvements (… which again saves time and increases efficiency but also popularity/embedding).
So I have to answer your question with no, I am not interested to become the communication officer because this role in a dedicated manner is neither necessary nor constructive on this level. I already make use of the community to save time and to get the job done effectively and efficiently, and I like to observe this efficiency and effectivity when I interact with Anaconda, ask.fp, KDE or other teams, and also rationalize what I learn and produce during collaboration. Each single problem leads to new perspectives, knowledge and improves my efficiency and effectivity, and sometimes it leads to new ways of reasoning, which reveal that seemingly-big time-intensive problems can be solved quickly and easily. Within Docs, my perception is that this development often does not take place.
I think there are possibilities to improve and to mitigate issues in Docs when the understanding of collaboration and community gets reshaped a little (… which leads to the new ways of reasoning I mentioned before). In either way, pushing this topic with reminders will not lead to solutions, but at the worst to alienation of other teams.
Some of the other points perhaps belong more to the second/related open topic and should be deepened / elaborated there. The starting point of the discussion there may also be a little better.
Hi guys, Pipeline error in any kind could happen due to various reasons. Continually bickering on this topic is counter productive.
CI pipeline fixed with this commit.
The subject of this thread is considered resolved.
We’re all working with competing priorities in all walks of life.
If I encountered a similar issue, I would have opened issue ticket with clear explanation and suggestions.
Vale linter CI script (in addition to vale CLI tool) started with good intention and spirit as noted in several meetings. What’s the big deal?
Indeed 
I don’t think so. There is no “burden” at all, at least not for me. But these things need time, nevertheless. And, there is nothing like “the” community, but there are many communities, sub-communities, micro-communities, and those are interwoven in many ways. And then there’s something like focus and division of labor. No one can take care of everything efficiently.
And in that spirit, it would be good to have someone who gets involved in the work of the Mindshare Committee from Doc’s perspective. And it would also be nice to have someone who focuses on the technical side of Fedora Docs, at least in part, and of course participates in the appropriate sub-communities to do so. But none of this has anything to do with a “Burden” of “the” community.
Yeah, and in the same good spirit, we had considered abandoning techniques like vale given the current resource situation because (a) we don’t have anyone to systematically take care of it, (b) other areas are more important than the docs team pages, so it’s not really worth the effort at this point in time (it would be different if we could include vale in Quick Docs on pagure). So there is no big deal.
Yeah, and add another one to all the existing, open and unresolved tickets we’ve been accumulating for months. We should somewhat keep in mind the factual cruel reality (sorry if I’m just appearing as the devil’s advocate right now).