tighting maintenance section definition

[valeriocomo]

Hi! As stated in the title, it would be convenient to be more concise with the definition of maintenance section.

In the actual definition, maintenance.contacts and maintenance.contractors are mandatory if maintenance.type has a particular value. For the first one, internal or community, contract for the latter.

It's not explicitly forbidden having maintenance.contacts occurrences or maintenance.contractors occurrences when maintenance.type it's not set accordingly.

So, I suggest to tight up the definition of this section in order to reduce personal interpretation.

This consideration starts from this issue.

There are two different proposals at the moment, one from me and one from @bfabio. Both the proposal starts from two different interpretation of the spec.

My idea is described as following:

• maintenance.contractors validation must be excluded unless maintenance.type is set to contract
• maintenance.contacts validation must be excluded unless maintenance.type is set to internal or community

The one from @bfabio is the following:

• maintenance.contractors validation must be excluded unless maintenance.type is set to contract
• maintenance.contacts validation would remain as is today

Every kind of change will impact the validator and the editor.

[tomootes]

@valeriocomo Maybe i'm oversimplifying this but still i would like to coin this. If we follow your scenario Valerio, we exclude contacts if we choose type contract. For community we exclude contractors. If this is so, can't we just assume that the contacts are contractors if maintanance.type is set to contract? For people manually typing a publiccode-yml file this would be a lot more user-friendly, in my opinion.