On Wed, 2017-10-04 at 00:53 +0200, Karl Pauls wrote: > On Mon, Oct 2, 2017 at 10: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? > > +1 > > Maybe we should require some kind of reasonable time/version note > along the lines of "This example has been developed for Sling 9" - > that way, users would have at least a rough handle on whether they > are > looking at something that might be outdated. Just a thought...
Sounds good, and not too much effort. Robert
