[PEP] Rename and document `pyomo.contrib`

[mrmundt]

Summary

There have long been discussions surrounding the name of pyomo.contrib - primarily influenced by the desire to make a more appropriately and clearly designated distinction between the main development team's core, supported features and those which are actively under development/"use at your own risk."

Rationale

The original intention behind pyomo.contrib was to be a location in which to place third-party contributions. While this is still true, the waters have been somewhat muddied regarding support level of these items. We'd like to rename the directory in order to bring clarity to the true intended purpose of this directory - that is, a place where active development and "use at your own risk" features are located.

Proposed Solutions

1. pyomo.contrib -> pyomo.sandbox
2. pyomo.contrib -> pyomo.devel

In either case, we want to add clarifying documentation in the new directory as to the purpose which will include: contribution guide, requirements on contributions (e.g., the fact that they are less strict than re-architecting of existing core functionality), etc. This documentation will require some iteration and will need review by the PMC.

[bernalde]

I totally agree with this! My vote would be for pyomo.devel (sounds more serious than sandbox and implicitly encodes the active development part of the description).

[emma58]

I also agree with this. I prefer sandbox because I'd rather emphasize that it's experimental and that there is little initial commitment to what we put in there--we might tear down the sand castle and start over. But devel would be fine too.

[Robbybp]

I think I prefer devel as well, mostly so I don't have to tell people to import my code out of something called sandbox. Worth noting that either name seems to encourage developers to move stable and widely-used code out of contrib, which is probably what we want.

[mrmundt]

The newest idea here:

• dev: a place where things are actively under development / no promise of stability
  • MindtPy, PyROS, Coramin, LaTeX printer
• apps: a place to store functionality that is not a core offering but has some level of promised stability
  • PyNumero, FME, TRF
• supported: the main offering; the place to which apps get promoted; everything that is "top-level" and is actively supported
  • FBBT (probably should go into core, is currently in contrib)

In this way, it's a clear progression of stability from dev -> apps -> supported. This way we can more adequately organize into an appropriate structure without a focus on "where did this come from" and a stronger promise of stability at different levels.

[Robbybp]

In this framework, is there a difference between extensions in supported and "top-level" extensions such as DAE, GDP, and Network? Or are you proposing to combine these somehow?

[jsiirola]

@Robbybp: The proposal is (I think) not for a supported directory, but rather that it is a "category" that covers everything not in dev or apps.