I don't think general scm submission access makes any sense at all for the aur. Now, for backend storage, *maybe*, but that is debatable.
I think an SCM backend would be useful. Having a history of changes would help if someone wanted to downgrade a package, or possibly even if someone found a bug in it. Without the two-way interaction with the SCM I guess there aren't any other benefits, and a history could be maintained via comments like it is now (or a special History relation). I'd have to look further into the advantages and disadvantages of implementing it this way.
I think the AUR needs to get 'back to roots', and focus on doing the job it needs to do, and doing it well. I think extraneous features that people want to add to AUR2 development should be punted, or forgotten altogether. Focus on core use and mainstream features.
Do you have any suggestions? I can't think of any other useful features at the moment. I haven't actually implemented any of the community stuff, or user management, so there's still more to dig into in terms of replicating features.
** Massive Sidebar ** As a sidenote, I think the TU devs (community) should have a more custom arch-dev like interface (cli tools, flag out of date interface, etc), and not really be included in the aur at all. Alot of the TU functionality was somewhat 'bolted on', and wasn't ever really a good fit for the real core use cases of the AUR.
Suggestions would be very welcome. I'm not a TU or dev and therefore am not familiar with the flow. I guess I'd have to setup AUR and possibly the main site locally and see what's available. I still won't get any insight into what's required or what would be better though.