A new vision statement for Fedora
by Matthew Miller
A few years ago, the Fedora Council updated the Fedora mission statement.
The result is functional but not particularly inspiring. It talks about what
we’re doing, but not much about the why. So, this year, we worked on a new
vision statement to serve as the proverbial “banner on a hilltop” that we
can use to rally our existing community and to attract new contributors.
Our draft is at:
https://communityblog.fedoraproject.org/lets-write-a-new-vision-statement...
We need your feedback and help in crafting a final version. Please reply
here in this thread to keep discussion in one place. We'd like to come to a
decision on this in Februrary.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3 years, 8 months
Revamping the Release Readiness meeting
by Ben Cotton
(Posting to many mailing lists for visibility. I apologize if you see
this more times than you'd like.)
You may have already seen my Community Blog post[1] about changing the
Release Readiness meeting process. The meeting has questionable value
in the current state, so I want to make it more useful. We'll do this
by having teams self-report readiness issues on a dedicated wiki
page[2] beginning now. This gives the community time to chip in and
help with areas that need help without waiting until days before the
release.
I invite teams to identify a representative to keep the wiki page up
to date. Update it as your status changes and I'll post help requests
in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC
meeting. The Release Readiness meeting will be shortened to one hour
and will review open concerns instead of polling for teams that may or
may not be there. We will use the logistics mailing list[5] to discuss
issues and make announcements, so I encourage representatives to join
this list.
[1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/
[2] https://fedoraproject.org/wiki/Release_Readiness
[3] https://communityblog.fedoraproject.org/category/program-management/
[4] https://apps.fedoraproject.org/calendar/council/#m9570
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
[Review request] Git forge requirements
by Ben Cotton
Council and community,
The community input period for CPE's git forge initiative is over. I have
collected and distilled the mailing list feedback into the list below.
Please comment by the *end of this week* so we can send Fedora's
requirements to the CPE team.
1.
As a Fedora contributor, I want the git forge to be self-hosted so that
Fedora is not dependent on third parties
2.
As a Fedora contributor, I want the git forge to be free/open source
software so that Fedora lives up to its Freedom value.
3.
As anybody, I want the git forge to have no JavaScript/cookie tracking
so that it is privacy-friendly.
4.
As a Fedora contributor, I want the git forge to integrate with FAS so
that it can use FAS to provide authentication and authorization.
5.
As a Fedora contributor, I want the git forge to integrate with
fedora-messaging so that it can be a part of automatic workflows.
6.
As a Fedora contributor, I want it to be easy to add new contributors to
a project (and optionally to enable self-adding) so that joining new teams
is low-friction.
7.
As a Fedora community member, I want to self-organize my personal and
team work by creating projects and groups of projects, by defining
different access levels, and by having basic contribution allowed for
everyone by default, so that I can contribute in full autonomy.
8.
[dist-git] As a Fedora contributor, I want the dist-git to integrate
with other packaging services (anitya, koji, Bodhi, etc) so that it can be
a part of automatic workflows.
9.
[code hosting] As a Fedora contributor, I want to encourage new
contributors with easyfix-like functionality so that newcomers can find
easy tasks to get started with.
10.
[code hosting] As anyone, I want good search of code, commits, and
issues so that I can find particular parts of the code or project history.
11.
[code hosting] As a software maintainer, I want pull requests to allow
me to rebase so that I can accept pull requests without waiting for the
submitter to rebase.
12.
As anyone, I want the URI to the archive (tar.xz, tar.bz2, etc)
corresponding to various code states (commit/tag/release/fork…) to be
regular and stable (ideally, identical to the Pagure URIs to avoid
reimplementing existing automation) so that I can point to point-in-time
snapshots of the repository.
13.
As a Fedora contributor, I want the git repos to be fully accessible
over https (read and write) so that I can contribute from environments
where ssh is filtered for security reasons.
14.
As a drive-by reader of Fedora docs, I want to click through to make a
suggested improvement without needing to set up a whole code-development
infrastructure so that I can make low-friction contributions.
15.
As a Fedora user, I want to easily create pull requests to any dist-git
repo so that I can make contributions to repos that I am not a maintainer
of.
16.
As a package maintainer, I can only commit to a dist-git repo if I am in
the Fedora packager group so that non-packagers cannot directly affect
packages.
17.
As a package maintainer, I can only commit to a dist-git repo if I am a
maintainer of the branch so that EPEL maintainers and Fedora maintainers
can be separate.
18.
As a proven packager, I can commit to all dist-git repos that do not
have special restrictions set by FESCo or are retired so that I can make
bulk package updates or step in as directed by FESCo.
19.
As a FESCO member, I can configure exceptions to disallow proven
packager access to a dist-git repo so that I can protect key packages.
20.
As dist-git repo admin, I can easily add other maintainers to allow
commit or admin access for dist-git repo by using their FAS username so
that I can enable others to co-maintain a package.
21.
As a dist-git repo admin, I cannot remove access to the repo from Fedora
infra, Releng or proven packagers without FESCo approval so that Releng,
infra, and provenpackagers have the ability to perform their functions.
22.
As a package maintainer, I can easily orphan a dist-git repo or branch
to show that it is not maintained anymore so that other maintainers can
adopt it.
23.
As a package maintainer, I can adopt any orphaned dist-git repo or
branch so that it has an active maintainer.
24.
As a package maintainer, I can easily unretire a retired dist-git repo
or branch so that it has an active maintainer.
25.
As a release engineer, I can easily approve unretire requests for a
dist-git repo or branch so that it has an active maintainer.
26.
As anybody, I can easily see the FAS usernames of maintainers for all
branches of a dist-git repo so that I know who to contact.
27.
As a non-releng member, I cannot remove any commits from any dist-git
repo that were used to build a Fedora package so that the release history
remains intact.
28.
As an external user, I can easily get a list of all orphaned or retired
dist-git repos and branches so that I know what packages need maintainers.
29.
As anybody, I can watch for issues or pull requests that are created for
a dist-git repository so that I can stay up-to-date on repositories I care
about.
30.
As anybody, I can easily get a list of all dist-git repos that I am
watching so that I can be sure it matches my current needs.
31.
As anybody, I can easily get a list of all dist-git repos that a
specific Fedora account has admin/commit access to so that I can see what
packages the account is associated with.
32.
As anybody, when looking at the dist-git repo it is clearly visible
which branches are still maintained so that I know what release versions
are supported.
33.
As anybody, when I look for a specific branch, EOL branches do not
clutter my view so that I can more easily see the active branches.
34.
As a package maintainer, I can easily request commit/admin access for a
specific branch or dist-git repo so that I can help contribute in a
low-friction manner.
35.
As Fedora infra, I can easily audit that no git repo was accessed
without authorization so that I can maintain the security of the Fedora
infrastructure.
36.
As Fedora infra/security response team, I have access to secure logs to
analyse the impact of unauthorized access to all dist-git repos so that I
can maintain the security of the Fedora infrastructure.
37.
As anybody, the dist-git web page of a repo points me to Bugzilla to
report issues for a repository so that I can file bugs for released
packages.
38.
As an ISV developer who contributes to Fedora, I can fork a dist-git
repo via mirroring, make changes, and submit them back to Fedora as
applicable so that I can contribute to Fedora.
39.
As a distro developer, I can fork dist-git repos via mirroring, make
changes, and submit them back to Fedora from my Git server so that I can
contribute to Fedora.
40.
As a Fedora contributor, I can use a public API so that I can develop
workflow tools for myself and my team.
41.
As a repository admin, I can define custom labels for a repo so that it
can support my team’s particular workflow.
42.
As a repository admin, I can define arbitrary custom fields for a repo
so that it can support my team’s particular workflow.
43.
As a Fedora contributor, I can file bugs and feature requests in an
issue tracker so that I can provide feedback or track desired work.
44.
As a Fedora team member, I can vote +1/abstain/-1 on issues so that I
can approve or deny proposals.
45.
As a Fedora contributor, I want issues to support inline images in order
to simplify the workflow for visual tasks (e.g. design work)
46.
As a Fedora contributor, I want a Kanban board so that I can visually
track the status of work and do project planning.
47.
As a Fedora contributor, I can perform issue and pull request actions on
mobile devices via a native mobile app or a mobile-friendly webapp so that
I can contribute while away from my desk.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
Where's the FPL?, mid-February edition (family vacation)
by Matthew Miller
Okay, I'm just caught up from DevConf/FOSDEM, but now I'm going to be
offline for a week for vacation. After that, I'll be back and everything
seems basically clear until Summit. If you have Fedora leadershipy things
that need attended to urgently, talk to Marie or Ben or any other member of
the Fedora Council. Thanks!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3 years, 9 months
Taiga board for tracking CPE epic briefs
by Ben Cotton
Hi all,
Following on from our conversation with Aoife at the post-DevConf meeting,
I have created a Taiga board we can use to track the epic briefs we draft
and send to the CPE team:
https://teams.fedoraproject.org/project/fedora-council-infrastructure-pri...
All council members have the ability to create and modify the cards and the
board is public for community transparency. I have created epics for each
quarter. We can adjust the settings as we start using this board more
heavily.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
Fedora Council video meetings
by Ben Cotton
Council members have just been invited to the monthly video meeting
series. I have created a page in the wiki[1] for scheduling and wish
list management. I will handle the scheduling, but if there are guests
or topics you'd like to see, please add them to the wish list.
For the rest of the community, there is a Fedocal event[2] for the
February meeting. I will also include it in the weekly Fedora program
update published to the Community Blog and in the announcements
section of the Wednesday FPgM office hours.
[1] https://fedoraproject.org/wiki/Council/Video_Meetings
[2] https://apps.fedoraproject.org/calendar/meeting/9695/
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 9 months
