Suspicious SIG creation and Forge organization request #573
Labels
No labels
category
budget
category
code-of-conduct
category
docs
category
elections
category
events
category
initiatives
category
mindshare
category
policies
category
spending-request
category
Strategy Summit
category
trademarks
Next Meeting
state
resolved
good first issue
help wanted
needs
changes
needs
reporter feedback
needs
triage
needs
vote
role
engineering
role
fca
role
foa
role
fpl
role
initiative lead
role
mindshare
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
No milestone
No project
No assignees
11 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
council/tickets#573
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I wanted to flag a recent Forge organization request that seemed unusual.
A user (cssushiman) filed forge/forge#654 requesting a new Forge organization for a "Software Engineering SIG". I closed the request as invalid for the following reasons:
I wanted to bring this to the Council's attention in case this is part of a broader pattern, or if there's anything else that should be looked into.
Also worth noting a possibly similar situation with forge/forge#669, which was a request for a Java SIG organization.
In this case, I went ahead and created the
javaorganization on Forge since the Java SIG is quite well established. However, I did not add anyone to theforge-java-ownersFedora Accounts group, and requested that the requester file an infra ticket to have sponsors added.The user who filed that request (monkeybean12) also appears to have only recently created their Fedora Account and is not a member of any other Fedora Accounts groups — similar to the user who filed the Software Engineering SIG request (cssushiman), who is also not a member of any groups.
It may be coincidental, but the pattern of brand-new accounts requesting Forge organizations for SIGs they don't appear to be actively involved in seemed worth flagging.
Is it possible to check the IP address to see where the requests originate from?
I agree, both deserve some scrutiny ...
See also mailing list discussion here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/M57QMN5BM34JBR7PD22VX5EV6PPHLL4H/#M57QMN5BM34JBR7PD22VX5EV6PPHLL4H
As for the Java SIG - it has been mostly defunct for a decade or so. I tried to revive it a few years ago, but the
java-maint-siggroup is now defunct too. As far as I know, there is just no coordinated package maintenance happening for Java packages (other than OpenJDK maintenance and minimal packaging stack maintenance done by ~two Red Hat employees).As for the Java thingie: It is an attempt to revitalize the existing Java SIG. A project I wanted to start when it crashed down some times ago as @decathorpe mentioned above (and I talked about with him). I’ve been working on this for a few months now on individual channels with various Java developers, with some success, as far as my time has allowed. A few like-minded people have now popped up, so hopefully things will pick up momentum from here. See the discussion at #lounge-java:fedoraproject.org
@ryanlerch please add me to the forge-java-owners so I can take care of this. We need the org anyway for the migration of docs to forge.
+1 to Java SIG, and thank you @pboy for co-owning this space. I would like to see the SIG page be updated to reflect current operations (new members, if the mission/scope has changed, etc).
Wrt the software engineering SIG request, I am -1. One member is not a group, software development as the purpose seems too vague to me and the request has not followed the process, as outlined. I would be happy to reconsider this as a SIG if/when there is more activity (people involved, stuff happening, etc) over time. Until then, as said, I'm -1.
Same as above:
+1 on Java SIG
-1 on software development SIG in its current state
Having watched some of the responses from the same or similar user name in multiple Fedora spaces, I've noticed bot-like patterns (frequent posting, pushy phrasing, immediate conciliatory tone when confronted) that I've seen in other communities. It may be that, with the interest in AI in Fedora documented in many external articles plus a new Forge, we've got some folks exploring turning bots onto the project. I think closing the request for a Forge space in this case is valid (and agree that, now that we have a sense of the Java one plus a need to move the docs anyway, it's safe to make it). Good to flag it either way.
As a side note, I do want to note that there are two different places on how to create a SIG:
Perhaps we need to update one or the other to match, or get the wiki page deleted and all links switched to the docs page?
FWIW the commops howto doc looks quite new, and to my knowledge the wiki page is still the authoritative source (for now).
We have been in the process of migrating all wiki content of a permanently documentary nature to Antora for years now. Once the Antora version is ready and published, we will insert a macro developed specifically for the wiki that will silently forward the wiki page to Antora (a process that the wiki usually defers). Recently, we additonally started a housekeeping process to finally delete those Wiki pages that have been forwarding for a long time, assuming that updates to their index have been made by all search engines.
The Antora page was created by @jflory7 5 months ago. No one else has worked on this so far. II’ll get in touch with him to see whether he or someone else at Commops can complete the migration.
As I understand it, the singular requirement for forming a SIG is creating a Wiki page that lists a SIG's purpose and members. This allows us to have a directory of all Fedora SIGs under the SIGs Wiki category. The new document seems to remove this requirement and suggests a couple alternative options for SIG documentation, but then we don't have a central listing of SIGs like we have on the wiki. I'm not saying we should tie ourselves to the wiki, but we should have a proper substitute. Also, forming a SIG by creating a short Wiki page is a easy, self-service process. I don't think we should make the Fedora Forge organization request process to create a git repository with documentation a prerequisite to forming a SIG. Some SIGs (e.g., those organized around packaging) my not need a Fedora Forge tracker at all, since work is managed through distgit, Bugzilla, or elsewhere.
@gotmax23 wrote in #573 (comment):
For whatever my opinion is worth: I think the Forge should be the official, central location for every SIGs and for all other teams, even if their central activity is elsewhere. (When it is, there should be a brief description and pointers to where the work itself is organized and where discussion happens.) And that should be updated/validated at least yearly; I don't think that's too high a bar for "is this SIG active?"
I agree that having
forge/<name>be a landing page for SIGs or other group efforts is nice (it's also what I've done with https://forge.fedoraproject.org/rust).But requiring it leads to a chicken-and-egg problem - you want to create a SIG, so you need an org on forge, but you can't create an org on forge unless you're an established SIG ...
It's also not a useful mandate, since it can't be enforced. People can just avoid it if they want to. And since the forge is not self-service, it creates too much friction for the design of SIGs.
At least with my FESCo and many-time-SIG creator perspectives, I would be against forcing such a bottleneck into Fedora.
So could there be a reality where SIGs are still welcome to form using the existing guide:
And then if the SIG needs resources from the forge, they can link to their wiki page in the issue?
I also like the CommOps HowTo guide. We should consolidate the information. It looks largely the same.
I completely agree with @mattdm. We need to organize our paperwork systematically, and do so in docs / antora.
But we also need to sort out the chicken-and-egg problem. Perhaps we could introduce a ‘sunrise’ phase, where a new SIG first gets set up and established on Wiki. An established SIG would then move to docs / Antora /forge.
And, of course, a list of all SIGs will need to be migrated as well. How to curate this is worth considering separately. But Docs will sort that out.
And, of course, a list of all SIGs will also need to be migrated. How best to organise this is worth giving some separate thought. But Docs will surely manage that.
Perhaps we need to split the SIG concept into two? Because it seems like sometimes all SIGs are not the same.
When you are just forming, you need something very light weight and self service. You need to figure out if there are actually enough like minded folks around willing to join and also enough to do in that area.
After you do have members and are doing things, you likely need more resources like dedicated matrix rooms or forge orgs or discourse tags. I think just setting up those things for everyone who comes along and says "I am forming a sig" is kind of a waste... if they don't have people and aren't doing things, those things just sit idle.
Anyhow, perhaps this should be a wider council discussion rather than in ticket here.
I think we could do that:
Each SIG can transfer between those two labels depending on interest
This proposal seems pragmatic and sound. However, it has the drawback that we cannot place and find everything under a single heading in one place. It introduces a distinction for SIGs that is uncommon in the broader community and requires explanation. Our structures are already complicated enough; we should avoid any further complications as much as possible.
One major advantage is that it would solve the problem of a SIG not wanting to deal with docs/Antora. However, we could also allow these SIGs to link from docs/Antora to wiki pages, where they can maintain pages with frequent changes according to their preferences. It’s not ideal, but perhaps a compromise.
A compromise may just be enough if we iron out the details
Y'all, this is pretty off-topic for this ticket by now. If you want to discuss updating the "how to create a SIG" to a more formalized process, please open a discussion thread about that elsewhere.
Agreed. I think theres enough sentiment from council to provide an answer on the original request, so closing this ticket now. And +1 to @decathorpe suggestion on discussing SIG documentation in a different forum for now.
@kevin commented:
Maybe offer them to build git & web on fedorapeople.org and observer for 6/12 month. There is a wiki article which describes everything fine. If there is no further movement in the 6/12 month time span, rejecting access to the forge. It was horrible to find things on pagure.
It would give room to the infra team focus first on tasks which are already established and running on the forge, including to implement new functions. (I primarily speak of new appearing users and not of users which are cumming back and already know how things work in the community)
Sorry to comment into a closed topic. I will close it again or it can be closed if I can not do it.