Clarify that input and output interfaces means APIs.

[evankanderson]

Digging on the wording from best practices (which this seems to have been lifted from), suggests that the current wording is due to this issue:

coreinfrastructure/best-practices-badge#450

"input and output interfaces" feels like it misses the point that this is focused on API documentation for connecting programs, which seems to have been the original intent.

[funnelfiasco]

I think this is good. It certainly seems to capture the original intent. I'm not sure if we want to also include filesystem IO and network port requirements here or if maybe should should be separate, similar requirements.

For installed software, it's important to know where it needs access. In particular, I'm thinking about things like Flatpak or mobile apps where the application is somewhat sandboxed, but may need access to particular resources (e.g. /tmp, $HOME, tcp/388)

[evankanderson]

I think mobile apps actually have this fairly well done with manifests. I'm not sure that desktop (especially Linux) software has the same sort of standard mechanism for spelling out requirements.

I think filesystem IO and network ports might be better as a separate requirement for open source which ends up being its own self-contained program with one or more processes. (e.g. compared with the large amount of OSS which is libraries which are built into zero or more programs.)

[eddie-knight]

Not sure I agree with this one... Inclined to think that other inputs and outputs need documentation as well— such as CLI input and output or filesystem i/o.

[mlieberman85]

Not sure I agree with this one... Inclined to think that other inputs and outputs need documentation as well— such as CLI input and output or filesystem i/o.

I agree with us being clear. Now some would argue CLI, sockets, files, etc. are part of the API but given that it's not a universal view we should be clear.

[SecurityCRob]

+1