adding a special namespace for easy contributing

[younesStrittmatter]

We could add a special namespace (for example, contrib) to autora (so src->autora->contrib), under which we could allow for easier contribution than in the src->autora namespace. That way, we can have contributors that don't want to bother that much with documentation or other details and quickly publish under the autora-contrib namespace (we would still have some form of qualitiy control but less strict, for example we wouldn't require tests, certain aspects of naming conventions, documentation..., and in the core-documentation, we would maybe only provid a link to these contib packages). If contributors (or we) want to contribute to the autora namespace directly, (src->autora) namespace, we would have a much higher review process.

[musslick]

That sounds interesting. How does it work with jsPsych? Do you also publish separate packages as a contributor or do you do pull requests into their main repository?

[younesStrittmatter]

jsPsych consists of a core repository, maintained by the core team, and a contrib repository, where users can contribute their own plugins and extensions. Anyone can contribute to both repositories, but the core team is responsible for maintaining and publishing the core repository, while contributions to the contrib repository are reviewed by the team but are not necessarily maintained or updated regularly.
The publishing for both repositories is not done by the contributor but by the jsPscyh-team. I think, that each contribution in the jsPsych-contrib repository is published as an individual npm package. So they have one repository containing a lot of individual npm packages (while we have a repository for each pip package).

[younesStrittmatter]

So, in short: the contribution gets pulled into a main repository but is still published as an individual package.

[younesStrittmatter]

I think namespacing the contributions also has the advantage that it clearly distinguishes between "core" and thoroughly reviewed packages, and outside contributions, while making it easy to contribute. When the user imports something from "contrib" it is clear, that this is on their own risk and it might break other code.

[musslick]

We should discuss having a separate repo for outside contributions then. I think that nicely complements the more rigorous sub-package solution. We could also run both and see which is most adapted.

[younesStrittmatter]

I am not sure if I understand correctly, but the contributions only controlled by the mother package and therefore the means to install the packages. If somebody wants to use our template to create a pip package under autora/theorist/malware, we can not prevent that. But we are only adding packages that we have approved to the autora mother package. Therefore the installation via autora["..."] is controlled by us and "save" (@hollandjg: That is correct, right?). So the control is in the mother package, which only contains approved packages either under autora/contrib or directly under autora/

[musslick]

I thought so differently. That is, we (as core team) also publish separate packages and treat them as external contributions (e.g., autora-theorist-darts). The only thing we control is whether we include the sub-package as a dependency in the autora "mother" package.

[younesStrittmatter]

You are still right. That is still the case.

[younesStrittmatter]

I'm sorry for the confusion. The mother package stays the same, but has an additional namespace contrib where outside packages are added as optional dependencies (the namespace contrib just signifies that this is an okay contribution but not something like autora-theorist-darts or autora-core which is developed by the AutoRA team itself)

[musslick]

Ah, so we would not review those and not add them as dependencies? I think I understand now, and it does make sense. Although now, I am worried that the contributors will get easily confused, about which contribution option to choose, so we should either evaluate whether this confusion is worth the functionality and/or make our best effort to communicate these different types of contributions to the community.