Prerequisites for pulling a package into the core team repo

[TomOne]

I think it is not specified which prerequisites a package must have to be accepted and pulled into this repo (in addition to the existing guidelines for contributing of course). That is a quite important matter, therefore we should specify it and write it into the README.md of this repo.

How about these prerequisites?

1. At least one member of the Chocolatey core team must be interested into the package to get it added to the core team packages repo. Therefore, before making pull requests for adding new packages to this repo, open an issue to ask if it can be added.
2. This repository is not indented as place to host random orphaned packages or package where the original maintainer is no longer interested to keep the package. Prerequisite 1 must be applicable to such packages.

This seems quite obvious, but nevertheless I’d add it (or a grammatically improved version) to the README.md.

Thoughts?

[gep13]

At least one member of the Chocolatey core team must be interested into the package to get it added to the core team packages repo. Therefore, before making pull requests for adding new packages to this repo, open an issue to ask if it can be added.

I am not sure that I agree with this, let me try to explain why...

Personally, I see one of the main benefits of the coreteam packages repo being the infrastructure that is offered, i.e. a ketarin instance that is running all the time and checking for new packages every hour. Not everyone has access to this, and although they have some automatic packages set up, they only check once when they first start up their computer, which may be every other day. I would personally welcome these contributions into this repository, and to see continued pull requests to update/maintain these packages when required.

The main premise that I would also like to get to is one central place to store the source code for any/all Chocolatey package. Obviously this doesn't scale well, but I would also like to see the number of core team members be extended to include other people, in order to help with maintenance.

[TomOne]

These are certainly valid arguments. But would you really pull in any package, e.g. poorly authored packages or packages for trash software? If this repository would grow and contain hundreds of packages or even thousands, it would require a lot of time to maintain them all and to provide fixes.

[gep13]

Yes, granted, I think that there will be some packages that we don't include in this repository, but let me be clear, what I don't want is solely for the core team members to be responsible for the packages that are contained within this repository. I would like to see this repository thrive on Pull Requests from original package maintainers continuing to update and refine their packages. The main benefit of this repository, as I have stated, is the ability for the ketarin instance to be running all the time, and near real time updates being pushed to Chocolatey.org. This is something that most people don't have access to, and submitting their packages to this repo becomes a mechaniam to allow that. Over time, I would hope that regular maintainers can also become contributors to this repository to help maintain other packages as well.

As for poorly authored packages, this is something that can be corrected before/after a package is pulled into this repo, so I don't think that this is a concern. We will certainly have to vet certain packages, but I feel that if it is good enough to be on the Chocolatey feed (i.e. it hasn't been blocked from getting onto there) there is no reason that it can't exist on this repository.

[Redsandro]

1. No trial-software;
2. Only silent or AutoHotkey installers;
3. Download from original source, not from third party;
4. As sec dry as possible, no customizations that one might find handy but another won't.

❔

[gep13]

These suggestions make sense to me, I think they are a good fit for this repository.

[gep13]

This is related to #20 and needs to be added into the wiki/contributing guide, if not already included.

[majkinetor]

I agree with resandro here. I will.make a suggestion for core guidance so we can argue.

[majkinetor]

New guidelines include almost all here.