Should each service repo contain a matching Tutor plugin?

[kdmccormick]

Context

For example: what if tutor-discovery lived in a subdirectory of https://github.com/openedx/course-discovery instead of https://github.com/overhangio/tutor-discovery ? This would not stop tutor-discovery from being its own package on PyPI; course-discovery would just need some GitHub Actions workflow to build and push it up.

There's no technical reason we couldn't do this. And based on @regisb's comment below, the Tutor project itself isn't going to discourage it.

But why?

I want to encourage service owners to maintain their own Tutor plugins. This is the only viable path I see in which 2U uses Tutor for all their Open edX services.

The best way for service owners to remember to maintain their Tutor plugins is for it to live in the same place as the service itself.

Acceptance

Talk to tCRIL and 2U about maintenance of Tutor plugins. Propose plugin-in-service-repo as a default working model to encourage the coupling of service maintenance and plugin maintenance.

[regisb]

In my book, the organization that hosts a repo is in charge of maintaining it. Thus, moving plugins to the service repo would mean that I no longer have to maintain them -- which would be amazing! (because I'm lazy) 😛

In terms of technical implementation, I see no reason why this should not work.

[kdmccormick]

Excluding the ones that are deprecated, the only remaining deployable app repositories are: edx-platform, credentials, and edx-notes-api (which really ought to be turned into an edx-platform plugin).

So, this question really becomes: "Should overhangio/tutor-contrib-credentials be merged into openedx/credentials?". And that is something we can leave up to the maintainers of each of those repositories.