Ticket #1170 (closed task: fixed)

Opened 8 months ago

Last modified 6 months ago

Working Group call for Volunteers

Reported by: mattdm Owned by:
Priority: major Keywords: meeting
Cc: jwboyer Blocked By:
Blocking:

Description

I'm drafting a call-for-volunteers message based on https://fedoraproject.org/wiki/Fedora.next/boardproposal. Will post draft here tomorrow morning.

Change History

comment:1 Changed 8 months ago by mattdm

Still working on draft. Turned out to be a busy morning.

comment:3 follow-up: ↓ 4 Changed 7 months ago by kevin

I'd suggest not sending it before say tuesday next week... as some folks may not have seen it on friday afternoon/weekend.

The only other question I have is is the "Fedora Commons" (ie, all the existing packages available in Fedora) under the Base design group, the Environments & Software Stacks Working Group, or neither?

comment:4 in reply to: ↑ 3 Changed 7 months ago by mattdm

Replying to kevin:

The only other question I have is is the "Fedora Commons" (ie, all the existing packages available in Fedora) under the Base design group, the Environments & Software Stacks Working Group, or neither?

As I'm picturing it, neither. That stays under FPC, FESCo, and of course individual maintainers and groups of maintainers.

comment:5 Changed 7 months ago by mattdm

Any other comments, anyone?

comment:6 follow-up: ↓ 7 Changed 7 months ago by notting

"Secondary architectures may just publish a collection of packages and not attempt to target any product at all. "

That's fine, but it means something much different in a new three-product world than it does in the current environment - how would they determine which collection of packages to publish?

I'm a little concerned by how short the sections are on docs/mktng/websites, given that they all boil down to "you now need to do some multiple of the work you were doing before." Perhaps they should be involved in the PRD process, including things like documentation and marketing as part of the product requirements.

comment:7 in reply to: ↑ 6 Changed 7 months ago by mattdm

Replying to notting:

"Secondary architectures may just publish a collection of packages and not attempt to target any product at all. "

That's fine, but it means something much different in a new three-product world than it does in the current environment - how would they determine which collection of packages to publish?

That part is in the already-passed board proposal message, not the call for nominations draft I want you to look at. :)

Anyway, what I was thinking was rings 0+1 as a minimum, plus whatever from the "commons" is reasonable on the architecture plus whatever else ring 2. But overall, I think that's a TBD.

I'm a little concerned by how short the sections are on docs/mktng/websites, given that they all boil down to "you now need to do some multiple of the work you were doing before." Perhaps they should be involved in the PRD process, including things like documentation and marketing as part of the product requirements.

Take a look at the other message, which I think covers at least some of that. I'm open to making that stronger.

comment:8 follow-up: ↓ 9 Changed 7 months ago by notting

So, are we going to have organizing resource around these committees? I'm thinking the equivalent of the feature wrangler/program manager for each of them, or shared between them. Organizational resources can help keep engineers on track for the deliverables required.

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 7 months ago by mattdm

Replying to notting:

So, are we going to have organizing resource around these committees? I'm thinking the equivalent of the feature wrangler/program manager for each of them, or shared between them. Organizational resources can help keep engineers on track for the deliverables required.

Yes, I agree that we need that. Maybe add a bit to the "group composition" section?

comment:10 in reply to: ↑ 9 Changed 7 months ago by mattdm

Replying to mattdm:

Replying to notting:

So, are we going to have organizing resource around these committees? I'm thinking the equivalent of the feature wrangler/program manager for each of them, or shared between them. Organizational resources can help keep engineers on track for the deliverables required.

Yes, I agree that we need that. Maybe add a bit to the "group composition" section?

I added "Feature Wrangler" to the long list of constituent groups. Or we can back that out. I think that *after* this message we'll work out guidance for the development of governance and product descriptions, and that's where that really belongs.

comment:11 Changed 7 months ago by mattdm

  • Keywords meeting added

also requesting that we add this to the meeting agenda for tomorrow

comment:12 follow-up: ↓ 13 Changed 7 months ago by toshio

I'm a little concerned about pacing -- It may make sense to have a release where we implement one working group for a new product, the base design working group, and possibly the stacks & environments working group. The deliverables for that release would be the current type of release and the one new product. this would allow us to prototype this new process and concentrate on fixing issues with just one new product/working group in charge of it.

However, it could be that making a longer development cycle will also address the pacing issue. I guess for me that means we need to decide something about the length of the next deployment cycle before I'm comfortable calling for volunteers for all three of the new product working groups.

comment:13 in reply to: ↑ 12 Changed 7 months ago by mattdm

Replying to toshio:

I guess for me that means we need to decide something about the length of the next deployment cycle before I'm comfortable calling for volunteers for all three of the new product working groups.

There is a cyclical dependency problem here, because it's hard to nail down exactly what changes (and time for changes) will be needed while the idea of what we're going for is vague. I don't think that we necessarily need to target all the changes for the next release, but I would like to get the planning work started sooner rather than later.

comment:14 follow-up: ↓ 15 Changed 7 months ago by toshio

<nod> I would be fine if what we commit to is somewhat vague. For instance -- if we're going o forge ahead with all three products for F21, to also say "F21 is going to have a longer than normal release cycle to start implementing the technical and governance/policy changes for the Fedora Rings Proposal. How much longer and what specific changes we're going to accomplish in that time is still being determined."

Basically to state that we know that what we've already allocated for the next release cycle is going to push us to a longer development cycle.

comment:15 in reply to: ↑ 14 Changed 7 months ago by mattdm

Replying to toshio:

"F21 is going to have a longer than normal release cycle to start implementing the technical and governance/policy changes for the Fedora Rings Proposal. How much longer and what specific changes we're going to accomplish in that time is still being determined."

+1

comment:16 Changed 7 months ago by mmaslano

  • Keywords meeting removed

AGREED: let's move on with proposal of Working Groups (+6,-0,0)

ACTION: mattdm to send out message as drafted

AGREED: Once more agreed Working Group proposal should be sent as draft and members have month for joining those groups (+5,-0,0)

Note: people will have month for signing in, so we do not need to discuss it next week. If someone change mind, add it back to meeting.

comment:17 Changed 6 months ago by mmaslano

  • Keywords meeting added

Last action on this ticket was a month ago. On devel list is a discussion about this topic even though it's not about concrete proposals or groups.

Do we want to tell people who signed up to start working on proposals?

comment:18 follow-up: ↓ 19 Changed 6 months ago by mattdm

Action moved to https://fedorahosted.org/fesco/ticket/1177 I think.

It doesn't hurt for people to start talking but I don't want the cart to get too far ahead of the horse.

comment:19 in reply to: ↑ 18 Changed 6 months ago by mmaslano

  • Keywords meeting removed

Replying to mattdm:

Action moved to https://fedorahosted.org/fesco/ticket/1177 I think.

I was looking for this ticket. Ok, there is WG nomination period will end on Oct 14 0:00 UTC.

So I will drop this issue from meeting, we can discuss it during Open Floor if we don't have too much agenda.

comment:20 Changed 6 months ago by sgallagh

  • Keywords meeting added

Working group self-nominations ended yesterday. Adding this to the agenda.

comment:21 Changed 6 months ago by sgallagh

  • notting was volunteered as co-ordinator for Base Design WG (mmaslano, 18:35:01)
  • sgallagh has volunteered as coordinator for Server WG (sgallagh, 18:35:23)
  • mattdm has volunteered as coordinator for Cloud WG (sgallagh, 18:35:31)
  • mmaslano has volunteered as coordinator for Environments/Stacks? WG (sgallagh, 18:36:01)
  • AGREED: working groups will have 9 initial voting members, including fesco coordinator (+8, 0, -0) (sgallagh, 19:08:28)
  • AGREED: Proposal to defer a week to seek other volunteers for Workstation WG coordinator fails (+2, 0, -5) (sgallagh, 19:13:55)
  • AGREED: Initial working groups due next FESCo meeting for ratification (+8, 0, -0) (sgallagh, 19:16:43)

jwb was nominated as Workstation WG coordinator since no acceptable FESCo member could be found. jwb accepted.

comment:22 follow-up: ↓ 24 Changed 6 months ago by sgallagh

Fedora Server Working Group Proposed Candidates

  • Jim Perrin: He will bring to the table an idea of what the CentOS project would want to see in CentOS 8 for its constituency (which is notably different from Red Hat's consumers, despite sharing a common code ancestry)
  • David Strauss: He maintains a large existing deployment of Fedora servers in production and will be able to help us identify its strengths and weaknesses when used in such a manner.
  • Truong Anh. Tuan: Representing the Fedora Ambassadors, he will be aiding us in producing information that will be useful when talking about this new product in public.
  • Máirín Duffy: As the representative from the Fedora Design Team, she will be invaluable in all conversations planning for the user experience and product announcements.
  • Kevin Fenzi: Representing Fedora Infrastructure, he will hopefully keep us grounded in what we can or cannot accomplish in a particular period of time (as well as having a wealth of knowledge around real-world deployment scenarios). He is also a member of FESCo, though not acting as coordinator.
  • Miloslav Trmač: Red Hat security engineer who no doubt work tirelessly to ensure that we ship a product that is tightly controlled and properly maintained, as well as representing other low-level security decisions. He is also a member of FESCo, though not acting as coordinator.
  • Simo Sorce: Red Hat engineer representing the identity and policy management space. His experience with both FreeIPA and Active Directory will be invaluable as we work out how to coordinate Fedora Server in heterogenous environments.
  • Jóhann B. Guðmundsson: Representing the Fedora QA team, I expect Jóhann to focus primarily on working to make sure that we do not make life any more difficult for testers than we strictly must.

comment:23 Changed 6 months ago by sgallagh

  • Cc jwboyer added

comment:24 in reply to: ↑ 22 Changed 6 months ago by jwboyer

Fedora Workstation Working Group Proposed Candidates

  • Owen Taylor: He will be able to discuss upstream Gnome plans and adds a lot of knowledge on desktop interactions.
  • Kalev Lember: He will be able to provide community focused input and feedback into what is needed for a successful workstation product.
  • Christoph Wickert: Long time Fedora member, will bring experience from both XFCE and LXDE desktop environments. Can help with inter-operability aspects between DEs, etc.
  • Lukáš Tinkl: Long time core KDE developer. Will be able to provide feedback and insight into that DE as well as what that class of user looks for in a workstation.
  • Jens Petersen: Will add i8n and developer experience to the team, helping the workstation product in those areas.
  • Ryan Lerch: Fedora Design representative. Will help with UI and design experience.
  • Matthias Clasen: GNOME desktop team lead. Lots of experience with Fedora and GNOME in a variety of aspects.
  • Christian Schaller: Desktop manager and Fedora packager. Brings a good knowledge of workstation products.

NOTE: There were no representatives from QA that nominated for this WG. I will be encouraging participation from all that want to pitch in anyway, but I'll explicitly try discussing things with QA as we go forward.

comment:25 Changed 6 months ago by notting

Just to restate what I said on the FESCo list, while I appreciate the nomination, I must respectfully decline.

comment:26 Changed 6 months ago by mmaslano

fyi Stacks group proposed mailing lists for all groups. Ideas? I created the ticket for discussion: https://fedorahosted.org/fedora-infrastructure/ticket/4080

comment:27 Changed 6 months ago by sgallagh

I think I'm going to revive the server@… mailing list for Server WG discussions.

comment:28 Changed 6 months ago by jwboyer

Mailing lists are probably a necessity, yes. I would imagine repurposing server@, the desktop list, and the cloud list for those WGs, but maybe a new list would be better.

comment:29 Changed 6 months ago by mmaslano

Environments & Software Stacks Working Group

Toshio Kuratomi as member of FPC and infrastructure he can help with guidelines and changes in infrastructure.

Petr Kovar Technical writer at Red Hat, working on RPM and Software Collections documentation. Long-time contributor to Fedora and GNOME documentation, i18n & l10n and related fields. He'd like to focus on providing good packaging documentation for Fedora contributors and users.

Tadej Janež "Pythonista" who would like to help in making Fedora the most attractive platform for upstream Python projects and developers.

Sam Kottler As a member of the Rubygems + Bundler core teams, he'd like to help make the Ruby stack on Fedora more robust and have a particular interest in integrating the runtime more tightly with SCL.

Slavek Kabrda Python maintainer, packager, developer of pyp2rpm and spec2scl. His interest is integrating Software Collections into Fedora and make them useful for wide community. Most experience packager of SCLs.

John Dulaney Representing the Fedora QA.

Honza Horak Databases team lead in Red Hat, package (co-)maintainer of several databases. He will try to find a way to offer both stability and new features within databases area.

Jens Petersen Haskell SIG, i18n Project, Proven Packager and Tester. He would like to help strengthen the support for Functional Programming Languages and the general Fedora software developer experience, and in particular to make it easier to package for modern programming languages for Fedora.

comment:30 Changed 6 months ago by mattdm

Cloud WG:

  • James Antill
  • Robyn Bergeron
  • Joe Brockmeier
  • Haïkel Guémar
  • Sam Kottler
  • Sandro Mathys
  • Matthew Miller
  • Frankie Onuonga
  • Mattias Runge
Last edited 6 months ago by mattdm (previous) (diff)

comment:31 Changed 6 months ago by kevin

AGREED: pknirsch will coordinate base design working group for fesco. (+7,0,0) (nirik, 18:47:16)

AGREED: working groups can decide if they want new lists when they meet (+7,0,0) (nirik, 19:15:35)

AGREED: working groups should have a governance document/charter by nov 15th approved by fesco

comment:32 Changed 6 months ago by pknirsch

Base Design Working Group

Dennis Gilmore: Fedora Release Engineer, Packager, Secondary Arch Lead. I want to make sure we can deliver everything and enable everything to work

Harald Hoyer: Technical team lead of the Red Hat Plumbers Team, including systemd, dracut, initscripts, util-linux. In the Base Design WG, I will make sure the base/core is small and efficient; and just enough base to serve the common needs.

Jaroslav Reznik: Fedora Program Manager. Work on scheduling/planning, groups coordination, change management.

Bill Nottingham: Red Hat Engineer, FESCo member, assorted technical leadership things

Jon Disnard: Secondary Architectures, Packager, and Fedora Ambassador. Nothing special; Generalist, and hacker. Linux operator/developer since 1997'ish. Mostly into or interested in Release Engineering aspects of Fedora.

Dan Walsh: Red Hat Employee, Base Operating System Security, SELinux, Containers, Virtualization.

Josh Boyer: Fedora kernel team

Subhendu Ghosh: Red Hat Employee, Fedora, RHEL, CentOS user, RHL HPC deployments in 1996, ex-Nagios plugins maintainer. I'd like to make Fedora a platform capable of deploying apps not included in Fedora, and for making Fedora manageable from a single instance to a million.

Last edited 6 months ago by pknirsch (previous) (diff)

comment:33 Changed 6 months ago by mattdm

Although this was in the meeting minutes, this probably deserves a devel-announce post of its own. Unless anyone objects I will send one today.

comment:34 Changed 6 months ago by mattdm

Or, as Stephen has just sent out a welcome message to devel-announce for the server, sig, let's do it that way -- everyone should send a similar message to devel-announce, please. (I sent one to cloud sig mailing list but I'll send another general one.)

comment:35 Changed 6 months ago by notting

  • Resolution set to fixed
  • Status changed from new to closed

From the 2013-10-30 FESCo meeting:

  • AGREED: base design WG approved (+:8, -:1) (notting, 18:27:56)
  • nirik to open a ticket to track working group governance proposals (notting, 18:29:17)

Closing.

Note: See TracTickets for help on using tickets.