Dear all,
You are kindly invited to the meeting:
Magazine editorial board on 2021-08-05 from 11:00:00 to 12:00:00 America/New_York
At fedora-meeting@irc.libera.chat
The meeting will be about:
This meeting is for editors of the Fedora Magazine site. The agenda primarily consists of deciding, assigning, and scheduling posts for the upcoming weeks.
More information available at:
https://docs.fedoraproject.org/en-US/fedora-magazine/editorial-meetings/
Source: Home - Fedocal
Minutes: Meetbot Logs
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2021-08-05/magazine.2021-08-05-15.00.txt
Log: Meetbot Logs
jakfrost will be EOW for this week
I just went though and made a best effort at sorting the articles that are ready for editing/publication by the date that the author reported them as “ready for review”. I’ve assigned them all dates for publication. They still need reviewers/editors.
Hi @glb , I’ll go through them this am. I looked at the Taiga notifications in email yesterday but was a bit preoccupied with things to do anything on them. Any preferences for your or @rlengland on editing roles? I notice Richard has been busy as usual in the editing area on some of them. Also, you mentioned the rest api for I assume Taiga, WP has one too, and I assume discourse does too. I was thinking of a containerized app which would use the restful data from those sources to present a dashboard for editors. I would likely choose to write it in Java given free reign.
Hi @jakfrost. #334 (NMState) appears to be the next article that should go out. It looks like Richard has already done most of the editing. I saw a few places where “Linux” should be changed to “Fedora Linux” and one typo. It also needs an image. I can take that one and get it finished tonight and scheduled for publication tomorrow.
As for the trying to sort the cards using the REST API, all I said was that it was something that I would be willing to look into at some point. What I had in mind wasn’t a dashboard. It was just a small helper script not unlike the python script we use to print out the due dates. Unfortunately, I’m quite busy right now getting things prepared for the Fall semester. So it would be quite a while before I could get to that. You are quite welcome to take on the project and write it in Java if you want. 
Hi Greg,
That sounds fine to me I saw you were editing yesterday and I stopped doing anything on it at that point since I didn’t know where you were with it (the the history was good so I could surmise you were editing it.)
As for the app, I was just wanting to use some of my other programming skills for a change, not just my industrial controls related abilities. Also, I have been doing some testing using the Quarkus framework with java and it is quite efficient when doing restful application development.
Do you have a link to the API?
Regards,
Stephen
On the topic of the API, is there any way to provide more visibility of the change of state of a sub-task? I’ve been thinking about articles that comprise a series and the one big problem I see with using a sub-task is the almost complete lack of visibility in Kanban. You have to know to go look at the “main” card to find the status of the sub-tasks.
I’m not sure but I can certainly look.
@rlengland: If you set the “zoom level” in the upper right to “Expanded”, then you will be able to see whether sub-tasks are “Ready for review” or not from the main view. I’ve set the “Ready for review” status as an “archive” state so that the title text will show up with strike-through on the main page (see card number 269 for an example of a series that has one part completed, but the other part still in progress). Is that sufficient?
@jakfrost: You can get to the API documentation by clicking the question-mark symbol in the upper right, then Taiga Resources->Technical Documentation->Table of Contents->API.
Thanks.
@glb Yes, the “zoom level” was exactly what I was thinking was missing. Now how did you happen upon that? I haven’t found a user manual for Taiga.
This will make me rethink how we handle the serial articles. At this point I’m thinking you have the way to handle this. A main card with sub-tasks. However, editors will have to remember to run in “zoom” mode to make that work.In fact, we’ll have to train the writers to use that mode as well or they may never find their cards
I ended up having a little spare time and I used it to write the small helper script that I had in mind. If you are interested in trying it out or seeing how it works, you should be able to clone it from the repository that I just created here: https://pagure.io/cardsort
I couldn’t figure out how to log onto Taiga from the script. So it is only able to read data from the Kanban board. It cannot update anything automatically. Consequently, the script just prints out what the order of the cards should be on the terminal.
I think it should provide enough of a framework that, in combination with the documentation mentioned earlier, others should be able to tweak it to query other information that they might find useful.
Enjoy.
I clicked on random things until I got what I wanted. I find that to be an especially fun method of discovery when you have administrative privileges.
For me, it has been “set once and forget about it”. It seems to remember how it was last set.
I think it makes sense in theory. I don’t think we’ve used it enough to say for sure at this point though. We may yet find that it doesn’t work in practice (e.g. what column should the card be in if some articles are published and others are not?), and I am OK with that.
Agreed. @glb First thought, main card stays in “In Progress” till all articles queued. But some trials will help sort this out better. We should annotate the cards as we trial, however, so we know what the status is and nothing gets lost. (?)
@rlengland: It sounds good to me. Right now, I have two states defined for sub-tasks – “in progress” and “ready for review”. Do you think a third state (e.g. “queued” or “scheduled”) should be added? If so, go ahead and add one. You should be able to do so here:
Taiga->Settings->Attributes->Statuses
Thanks.