Within the Fedora Project a small group of editors provide support for an on-line magazine.
Articles for this magazine are created by people with many connections to the project. These
range from project managers, to developers, documentation writers, and simple users of the
Fedora Linux O/S.
Each author opens a Discourse topic and supplies a description and outline of the article
via a template. The editors need a way to communicate with the authors, track what the status
of their article is, as well as simply who the author is. This is being done by using the
Discourse topics. The author, by creating the topic is, by default, “responsible” for that
article. The editors edit part of the template to assign editors, update the status, and
provide other information for the shared editing process.
There are occasions when the responsibility for an article changes. This may be a new author
assuming the responsibility, or an editor needing to create and assign an article to an author.
This re-assignment process can be done by using the “Assign” option for the topic.
However, an issue arises when the assignee is not a member of a group that can be assigned to.
This is most obvious with authors who have no higher lever TL status or group membership.
Their “userids” simply do not appear in the list when an attempt is made to search for and
assign the topic.
What is needed it a mechanism to allow a non-group user to be assign a topic. Or, perhaps, a
group that can be created for anyone with a FAS account (FAS - Fedora Account System). This
account is a requirement for authors writing for the Fedora Magazine.
I note that those that can not be assigned-to also appear to NOT be in any FAS group, although
in at least two cases that were checked they where a TL1. They have, however signed the FPCA
(Fedora Project Contributor Agreement). This leads me to suggest that if we could create a group
containing all the FPCA signers we might be able to assign to those folks.
Hey @rlengland, thanks for opening this topic. This is something that I need to look into with the Discourse support team. I’ll share this topic with them and see if I can get answers, or if someone might be able to ask directly here and help us debug how to make this workflow possible.
I think there are multiple teams which could benefit from this, especially as the Community Blog is considering a migration to Fedora Discussion as well.
For the benefit of public knowledge, here is the reply I received from our Discourse staff team. (They replied right away, I was the slow one here.)
I have made the change and added fedora-contributor to this field. @rlengland, if you could test, validate, and confirm this is working as-expected, that would be great. Thank you!
@jflory7 Remember this? Any chance we can resume the discussion with the Discourse folks? The only folks that appear to be available for reassignment seem to be admins (?).
The suggestion to add “fedora-contributor” to the “Assign allowed on groups” appeared to have no effect.
Is there another group that encompasses all the FAS signatories?
Hey, while you are at it with fixing things on Discourse, why did this “Assign” button suddenly show up at the bottom of every topic thread under every category on Discourse?
You should fix it so that doesn’t show up everywhere like that. It doesn’t really make sense except for the topics under the workflow categories.
That setting change was made by @jflory7 in an attempt to allow the Magazine editors to assign topics to article contributors who did NOT originate the article as describe in the earlier comments.
It’s tricky to see how this site is configured, as I’m not an admin. I can have a play around with one of my test sites and see if I can come up with anything, and we can compare it to how this is set up.
It might be useful to more actively rationalize site administration. Who is admin, who can/should act as one and in what circumstances, how to document, etc.
The general issues we have are to a large amount the result of many people being site admins and acting when the situations seems to fit, without coordination and without documentation, and often also without taking the time to dig into the context. We had site admin actions that have shown site admins to not know that TL4 != mod, which itself is not necessarily an implication for site administration, but illustrating lack of knowledge of the context in some cases when acting: this is not a good practice, especially if we want to increase trust to Discourse (e.g., among developers).
Direct consequences are a lot of unknown Discourse behavior and unclear configurations. Indirect consequences have already reached to non-compliant “half-deletions” of user accounts due to not knowing of the rules (which we had already before the guidelines) and not knowing how Discourse is integrated with FAS.
Our discourse was partially used like a test environment, but in production. Not sure if that really has changed? There are still many people site admin, even some I have never seen here in Discourse (and I’m here quite a while now:).
Maybe it is useful to start with re-evaluating the site-admin list at all? And add some transparency? Or (re-)evalaute even more? I mean, if Discourse becomes the center of the community, site admins have a power exceeding the CoC committee and to some extent even the Council (and their impact might also exceed many packagers that soon have to use, e.g., 2FA).
That said, I’d be +1 to have especially Greg and Kevin contained in the site admin list, as they have already some experience with Discourse site administration and have started to “rationalize” the state of our Discourse.
Sure. My rationale is that Greg Sutcliffe has stated that he has managed to set up his own local test environment where he can test Discourse configurations before applying them here on this production site. Also, I’ve seen him helping others to understand Discourse configuration. (Also, I was impressed with his work with helping to analyze the AI/ML Survey.)
+1 from me for doing a purge of the site-admin list.
A yes to all your points But the real value comes not before all site admins (or with regards to more recent happenings, “site admin accounts” rather than “site admins”) act in such ways
You might review what Site Admins engaged on the page you referred to Since the time the process of analyzing our currently-not-fully-understood Discourse has begun, it’s usually Kevin and Greg to work on it. That’s why I would indeed like to see both of them in any future (hopefully much shorter) site admin list.
So, I have my admin status now, and I’ve been looking into this.
As I understand things, only members of staff or magazine-editors can assign people to a topic (this is set in the Team Workflows > Fedora Magazine settings). However, the list of "who can be assigned is global, it’s set in the site settings.
Given only the staff & editors can do assignment, is there any reason not to use trust_level_0 as the list of possible assignees? That will be everyone on the site, because a new account starts at TL0. It can’t be abused because only the aforementioned groups can do the assignment.
My only concern is that it’s quite a long list, but you can type to filter, so … shall we try it?
