For the moment, envision this interface as a website. There is a button "Make me an Author". Pressing that button takes you to a little form to fill out to provide just a basic biography. Who you are. What you want to share about what you do. Contact information.
As an author, you get the ability to create new packages. If you are an author of an existing package in Sobyk, you can also request to be listed an author but pulling up that package and clicking a menu item "List me as an author". A site administrator, or a co-author who is already attached to the project can approve that.
Authors will have several roles in a package. Note that all of these roles only apply to the database maintained by Sobyk. How code is managed internally in a project is entirely outside the scope of these rules.
Creator. A creator is the initial author (or authors) of a package. The role is a largely ceremonial. You get a listing that nobody can ever scrub. That's the joy of being a creator.
Benevolent Dictator. The Dictator role has three jobs: Approve access changes, Settle Disputes and expel evildoers. Creators have the all of the powers of a Benevolent dictators. The role is is only created for forks of a project. The user who creates the fork becomes the fork's Benevolent Dictator. The BD role can be given away, but it can never be taken. If someone wants to take control of a project, they always just create a fork.
Maintainer. A maintainer is someone who actually maintains the listing for a package. The Creator or Benevolent Dictator of a package has all of the powers of a maintainer. Maintainers decide on release schedules. Maintainers have to press the buttons on the website to officially bump versions for projects. They also provide updated locations to find the source code for a project, and where to find the documentation, and so on.
Contributor. A contributor has some role in the project outside of the data that Sobyk manages. A maintainer may simply want them listed in the credits. Maintainers can also grant them powers like making blog posts, or answering user questions on behalf of the project.
So with that side-track over, what information does an author need to tell us about a package?
Well we should start with a name. Internally we'll be using UUIDs because names can change. But humans can barely type uuids. We need something they can search for. Ideally, the string they will be sending to package require.
Pick from a list, or invent your own. They are just text tags for searching.
There has to be somewhere that a user can get information about this package on the web.
Tarball/Git/Cvs/Fossil. We don't discriminate. However we can point a build system to get your tasty package is great. For the present, only one feed at a time, though. Ideally whatever your dev team is actually using
Give us, in a few words, what your package does and why we should use it.
What type of package is this: Binary Extension, Tcl Script, Tcl Library, Kit Component, or Framework
We all stand on the shoulders of giants. If your package needs another package, list those here.
In addition to those fields we need a list of releases. Each release gets a date, a version, a short description, and either a download location or an SCM tag.
Many packages are bundled with libraries. This is a list of what libraries (or other collections) this code was a part of, and which version was distributed. If a package is issued via Roy Keene's Teaparty, this area will have a link for how to download it.
Either a human description of how the package is built, or a machine executable script generated by the Sobyk tool.