Ever since the release of axoloti, its been fantastic the number of contributions we have had.
But this success (and the popularity of the forum) has meant its getting difficult to find objects and sub patches that have been contributed, and i think we need to organise things a little better.
the proposal below is not the ultimate goal, but something that I think we can do reasonably easily, and Ive time to implement in the client etc... and that later we could migrate to a different solution should we wish to.
Forum: User Library Category
A user will be allowed ONE topic in this category, on the first post, they can list all their contributions. split as :
objects - axs, axo (and associated axh help files)
demos - complete patches
firmware - firmware extensions
these files can be initially attached to this first post, and should include a version number and short description. following post in the topic can be used for further description, examples and also for others to discuss.
(also ensure you put your name/license/description in patch settings!)
we will encourage all users, to like, give feedback to authors
once you contribute, you will be 'granted contributor status' and will be PM'd to ask if you wish to become a collaborator . (see below )
Note: if we seen more than one topic per user, we will merge topics, we want to keep the number small.
Repository : user library repository (contrib.)
a. we will create a new repo (github.com/axoloti/contrib ?) that will contain user contributions, which collaborators will be able to contribute to.
(collaborators is the term used by github, so hence we need to re-use this)
the license agreement on this repo will be 'free for use', but the contributor retains ownership
collaborators will need to be registered with github.
b. I will extend the Axolotl client (using JGit) to do 2 things:
i. have a sync function which will allow ALL users to download and synchronise the contrib objects, this will sync into the current axoloti document folder as a contrib folder.
ii. allow collaborators to contribute new objects/demos/firmware.
(the hope is to 'hide' git away as much as possible for day to day use, but more advance options will have to be done using conventional git tools)
iii. the user library will appear in the object search windows as 'contrib' and then hierarchy
c. when a user is a collaborator, they should still post on the Forum : User Library, but instead of attaching the contribution directly, they can simply say its in the user library, and name it
e.g. midi/ctrl/launchpad.axo (in user library) . this will of course allow also for discussion for your users.
again, check you patch settings are filled with relevant info
some other note:
- We will also need that some collaborators help keep the 'user library repo' tidy, and perhaps 'police' certain aspects e.g. ensure copyrighted material is not committed! (lets call them 'maintainers')
- The contributor is responsible for maintenance and ensuring it works on future versions etc.
- If you would like to volunteer as maintainer... but are not a contributor, that is cool too.(collaborators will already have permissions to do this anyway)
- all collaborators will be able edit/delete other contributions... thats just the way github works. (but of course changes can be reverted as its version control)
some complications... which I think we will just have to 'work through'
patches/objects not working.
theres always a chance that certain objects don't work, or stop working after an update, and the contributor does not maintain. this ends up being 'dead objects' which is often frustrating for users.
if it persists not working/complaints etc, then I think the maintainers will just remove it.
(we cannot start passing the maintenance obligation on... with 100's of objects this will just be impossible)
samples (and other 'media')
we cannot have large samples included (size limit?) , it will just take too long for an end user to synchronise, and we have to remember they may be completely uninterested in your samples/demo!
no copyrighted material can be uploaded ... including anything from commercial sound libraries.
(fortunately, uploads contain username uploading... so enforcement will come after you )
I was thinking we would 'outlaw' samples, and only allow axo/axp/axh/axs BUT this would mean many demos just would not work/be useful
demo uploads (axp)
it would be contributors responsibility to ensure all dependent objects/samples are uploaded correctly.
ok, hardest topic for last
there are two possibilities i see:
i.e. every contributors objects get put together, perhaps most logical for users, or we split by contributor.
I think I favour the second, as it kind of makes the contributors recognised, and also if there are issues, end-users will be know who is looking after it....it also means if two contributors could use the same name without issue e.g. drumseq
(remember: the object search window does matching, so in both cases if you type launchpad , matches will be found regardless of hierarchy and also duplicates will also be listed)
some of this has been raised in a thread here, but I wanted to bring together a 'full proposal' and thoughts in one place.
I'll repeat, I think a database/web front end would be better BUT I think (now!) waiting for that to be developed might be a mistake, as we all have lots to get on with, and perhaps this is not a big priority BUT at the same time, I think it would be great for users to have easy access to user contributions.
so.... what are your thoughts? a good first step? have i missed something?
one parting thought, I know there are better ways to do some of the above (e.g. packaging demos)
BUT can I please ask
- we keep 'expectations' in check. i.e. lets not have suggestions where its expected someone else has to develop it. this is aimed as a starting point, with relatively little dev effort required not necessarily the end game
- bare in mind, whilst you can ask people to do x,y,z e.g. tagging, if there are too many 'rules', they will either i) get it wrong ii) not do it iii) decide its too much effort to contribute. ... so we need to keep it easy/simple