Formalizing a process for adding/removing services to KDE's infrastructure?
Open, WishlistPublic

Description

Proposal

It seems there is currently no formal process for adding or removing services to KDE's communication and collaboration infrastructure. I think it would be beneficial to define one. The process could include, for instance:

  • When adding a new service: commitment to fulfill of some basic requirements, such as maintaining the service for a certain amount of time or monitoring its use so the service can be retired when no longer needed.
  • When removing a service: require justification for its removal and a plan for archiving content for posterity.
  • For both adding or removing a service, a process for community discussion and support/rejection.

The exact requirements can be discussed later. Importantly, the process does not have to be complicated or overly restrictive, only clear about what the expectations are and plans for fulfilling them.

This proposal may be relevant to the KDE goal Automate And Systematize Internal Processes.

Examples of such (semi-)formal processes at KDE include requesting an email alias or getting a developer account.

Although adding/removing services may not be a frequent issue at KDE, I think it could be beneficial to define one.

Why formalize a process for adding/removing services?

KDE's communication and collaboration infrastructure include many important services. New services are occasionally added, and others get retired. Without some upkeep and curation, over time this can lead to KDE's infrastructure becoming fractured, unmaintained, or unused, and historical information can get lost. Moreover, it is not clear if such decisions are always made collectively or individually.

A (semi-)formalized process may help mitigate this and keep KDE's organizational infrastructure useful and up-to-date for contributors. Furthermore, although 100% consensus with such a diverse group may be difficult or impossible, defining a formal process to add/remove services can make such decisions transparent and fair. Moreover, by clearly defining the process, it can also possibly be streamlined and simplified.

joseph created this task.May 11 2023, 12:14 PM
joseph triaged this task as Normal priority.
Restricted Application added a subscriber: sysadmin. · View Herald TranscriptMay 11 2023, 1:08 PM

Perhaps some questions for the community:

(1) Which services have we retired/added recently? What are the reasons we retired/added them? What was the decision-making process?

(2) Are there services we want to retire/add? If yes, which ones? Is there a plan?

(3) Are there services causing problems? Which ones? Is there a reason we have we not retired them?

Some answers I am aware of:

(1) Which services have we retired/added recently? What are the reasons we retired/added them? What was the decision-making process?

RETIRING

ADDED

joseph added a comment.EditedMay 30 2023, 3:41 PM

(2) Are there services we want to retire/add? If yes, which ones? Is there a plan?

  • Account managers identity.kde.org / my.kde.org are to be retired (I believe). I do not know of community discussion at the time of writing.
joseph added a comment.EditedMay 30 2023, 3:41 PM

(3) Are there services causing problems? Which ones? Is there a reason we have we not retired them?

lydia added a comment.Jun 5 2023, 3:23 PM

In general I think it'd be good to have a lightweight defined process for both adding and removing official services.

Lightweight would definitely be key here. Historically decisions have been made by discussion on our mailing lists.

What sort of process were you envisioning?

This is just an example of what I could imagine, but I am not married to this proposal and perhaps you have other ideas:

Minimum:

  • Public discussion over mailing list
  • Support from one Sysadmin and one member of the KDE e.V.

Additionally, 2-3 sentence description with the following:

  • When adding a new service: who will maintain the service and for how long, a commitment to monitoring use so service can be retired when no longer in use.
  • When retiring a service: justification for its removal, plan for archiving content.

We've usually kept the KDE e.V. out of governance matters, so not sure it is a good idea to require that a KDE e.V. member supports infrastructure proposals.
Having Sysadmin buy-in / approval definitely makes sense as something may look awesome but actually not be practical to deploy.

Agree 100% on the public discussion on a mailing list - that has usually been how we have done things.

One thing we have done in the past when there is a particular type of service and several alternatives has been for these various alternatives to be evaluated by one or more groups within KDE, with pros/cons then being discussed before a decision is reached.

Thoughts?

This comment was removed by bcooksley.
kpj closed this task as Invalid.Jun 25 2023, 5:52 AM
kpj lowered the priority of this task from Normal to Wishlist.
kpj removed a project: Sysadmin.
kpj removed subscribers: sysadmin, neofytosk, adam and 4 others.
kpj removed a subscriber: kpj.
This comment was removed by bcooksley.
This comment was removed by bcooksley.
This comment was removed by bcooksley.
duffus reopened this task as Open.Jun 25 2023, 5:54 AM
duffus raised the priority of this task from Wishlist to Normal.
This comment was removed by bcooksley.
kpj closed this task as Sealed.Jun 25 2023, 5:56 AM
kpj reopened this task as Open.
kpj lowered the priority of this task from Normal to Wishlist.
abetts added a subscriber: abetts.Aug 29 2023, 3:53 PM

I wanted to also mention that whenever infrastructure is added or removed, we should do some change management to prepare the community if there is impact to them. Main aspects of a change include:

  1. Establish a vision
  2. Involve stakeholders
  3. Develop a change plan
  4. Communication
  5. Account for resistance and risks
  6. Celebrate success
  7. Review or retrospective

While we may not do all of these, I think key aspects are to establish the end goal, talk to the right people to involvement them early, develop an action plan and communicate. Communicating should not be a one time instance. We can prepare the community for change by creating preparatory communication focused on channels where our users are present and deliver change in a piecemeal approach.