Collection of this group's data for a LLM-powered weekly report #13525
Labels
No labels
after freeze
automation
backlog
blocked
change-ack
change-nak
change-noreleng
changes
Closed As
Can't Fix
Closed As
Duplicate
Closed As
Fixed
Closed As
Fixed with Explanation
Closed As
Get back later
Closed As
Grooming
Closed As
Insufficient data
Closed As
Invalid
Closed As
It's all good
Closed As
taiga
Closed As
upstream
day-to-day
dev
docs
easyfix
epel
f26
f27
f28
f29
f30
f31
f32
f33
f34
f35
f36
f37
f38
f39
f40
f41
f42
f43
f44
f45
fedora
groomed
high-gain
high-trouble
in-progress
in-review
investigation
legal
low-gain
low-trouble
mass rebuild
medium-gain
medium-trouble
meeting
mini-initiative
new_artifact
ops
pdc_retirement
rawhide
RCA
review
script
sidetarget
sprint-0
sprint-1
sprint-2
sprint-3
sprint-4
sprint-5
unfrozen
waiting on external
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
release-process
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
releng/tickets#13525
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?
Hi folks,
I'm generating a weekly report of activity in the Fedora project centered on teams and SIGs, it's called This Week in Fedora. This generation uses an LLM. The goal is to make it easier to catch up with everything that's going on in the project, and to give visibility to each group's work and requests for help. I think that from a newcomer's point of view, having an insight on what a group is working on at a point in time is helpful to decide whether it's interesting and worth contributing to.
I'm collecting activity from:
rel-engmailing-list#release-engineering-teamtagIn the latest version, I've added the possiblity to gather messages exchanged in Matrix channels. The
#relengchannel is public and its history is available to anyone, but a quite a few people in mutiple Matrix channels were unhappy about the LLM collecting this info, for various reasons.I would like to know whether this group is OK with my program collecting and submitting info to an LLM from the following sources:
I would like to make the case for source 3 (the Matrix channel) because I think it's less obvious: knowing the "tone" of a conversation and the currently discussed subjects before joining is very important to help contribute to it. It's like when you're added to an empty group chat and you don't know how to start. That's why we show history to new channel members, and this would be the same idea at a higher level. Plus there's actual work going on in there for a lot of groups.
That said, I recognize that the form of the tool influences its use, chat messages are usually less thought-through than emails or forum posts, and members could be indimidated that something they write there and regret end up in a visible summary (the program respects message edits, but anyway).
Since my goal is to foster participation, the one thing I don't want to do is to hinder it in another way.
I know I've asked this in the chat yesterday but someone in another room noted that people can easily miss Matrix messages, which it true.
Please decide which collected sources, if any, you are OK with (and if you work in other places that you would like to have collected, of course (I can do RSS feeds!)). If the group is OK with Matrix channel collection but some individuals aren't, I can also exclude certain Matrix usernames from collection throughout the Matrix channels that are not meetings.
I'm happy to answer questions if you have any. Thanks!
I'm personally fine with it (at least for now).
If it turns out it causes problems/confusion/sending information we don't want to, we may want to adjust it later.
Alright, I'm adding the channel to the collection, feel free to change your mind at any time :-)
+1 with nirik's thought, good to go.