Child pages
  • Plugin/component retirement process

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. When a broken or unused component is detected anyone can propose its retirement as long as the steps described here are followed;
  2. Create a discussion thread reporting the situation and trying to discuss a way not to retire the component. If we find people willing to work on it, is great; otherwise, the retirement process continues;
  3. After the discussion, a voting thread should be started to check if everybody in our community is on the same page; the voting window should be of 48 hours. If people are against, we keep discussing until we find a middle ground. Retirement is a very delicate process, so everybody should agree upon it;.
  4. If no objection arises or no one volunteers to maintain the code, a Jira ticket Github Issue to disable the component/plugin is created. The Jira ticket Github Issue should describe the situation and link the discussion and voting threads;.
  5. An announce in our mailing lists of the road map of retirement and a date for the final removal should be defined and presented in this roadmap (six months after the finalization finalisation of the voting thread);
  6. A patch (PR) to disable the code in the build must be created. This will require reviews and merge (our standard PR process is applied here);
  7. A Jira ticket Github Issue to execute the final removal of the code is created;
  8. When the final date comes by, a patch (PR) for the removal of the code is created. Again, this will require reviews and merge (our standard PR process is applied here). The contributor proposing the retirement should be in charge of managing these time lines, running emails threads, creating Jira tickets and Github Issue and submitting PRs;.
  9. Congratulations!! You have removed an old and tired plugin; now, it (the retired plugin) can take the vacations it always dreamed of.

...


Here goes some frequently asked questions in respect to this issue:

  • Would not it be better to just disable and let the retired component there?
    No, it would not!
    Code that is not used should always be removed.  Broken code should never be kept in our code base; it only slows down our development process and might serve as terrible example for newcomers.
  • What if I someone in the future wants to get the retired component and put the energy and resources to make it alive again? Would not it be a good reason to keep the code?
    If someone desires to work on top of a retired plugin, anyone can do so by getting the commit before the removal commit and then he/she can work to resuscitate it. Therefore, there is no reason to keep the code. We use a versioning system; code removed/changed will always be in our history. Anyone using Git can easily recover a removed chunk of code.
  • Will you accept a resuscitated component?
    Yes, as long as it works, meets our quality standards, has user and maintainers.

 

 

 

...