I think this is a good start for criteria of acceptance (or moving to attic).
I'd add a README.md with the supported version of Sling and basic build and usage instructions. A user should be able to understand why they want to install the sample just from the README. It might be a good idea to look at overlap for various samples. If one sample focuses on Sling Models, another sample should focus on OSGi, Thymeleaf, Provisioning, or CA Configs. If samples could be cut down, they may be easier to maintain going forward. • It builds • No snapshot dependencies • No configuration • No extra bundles • A decent README • Doesn't re-tread too much ground of another sample. On Mon, Oct 2, 2017 at 2:17 PM, Robert Munteanu <[email protected]> wrote: > Hi, > > I think that our samples could do with a little more usability. They > are fine as code samples, but sometimes fail short when trying them > out: > > - missing configuration - usually loginAdmin whitelist > - extra bundle dependencies > - dependencies on SNAPSHOT/unreleased bundles > > I'm not making any judgements on the usefulness or code quality, just > on how easy they are to load into a Sling launchpd. > > I would like to propose some ease of access requirements for the > samples: > > - build succeeds ( D'oh, but we have a sample build that's been failing > for some time ) > - no SNAPSHOT dependencies ( we want users to be able to build without > adding extra repositories ) > - no configuration required > - no non-default bundles required ( should deploy in the default > Launchpad ) > > The reason for adding these requirements is that they should be > immediately accessible and useful for our users. Asking them to chase > configurations and other bundles, especially when just starting out > with Sling, is too much in my opinion. > > I'm not suggesting that we remove modules which don't satisfy these > criteria, just that we work towards that and ask more of any new > potential samples. > > Thoughts? > > Robert >
