Metascore/PrototypeA

From Metagovernment - Government of, by, and for all the people

(Redirected from PrototypeA)
Jump to: navigation, search

This is a basic outline of the initial implementation of Metascore.

The software runs on a central server and is delivered through a browser. The software is written in Python and uses the Django web framework. A relational database is used as the datastore for users, messages, tags, scores and various other design specific models, described later in this document.

Articles are stored in a mercurial repository and editable through a wiki like interface, as well as locally through the standard mercurial software. The fronted uses XHTML, CSS and the Dojo toolkit.

Contents

Demonstration

A developmental version of Prototype A can be accessed at prototype.metascore.org and you can also watch a video introduction.

Participation

This document is a work in progress, please give feedback and edit freely. Some of the ideas here have been discussed in other places and the reasons for certain decisions may not be given. If the reason for a specific decision is unclear, please ask, add references, or add the reasons to the document.

The progress of the implementation is documented in the PrototypeA_Roadmap.

Fundamentally, PrototypeA is a fronted to mercurial, so a good understanding of DVCS is essential to understanding how the software works. If you are not familiar with mercurial or DVCS, you may want to check out the introductory sections at: [1]

The repository associated with this prototype is managed in Mercurial and is available on bitbucket.org.

If you have mercurial installed, you can use the command:

hg clone https://bitbucket.org/mbarkhau/metascore/

A guide to get get metascore up and running on your local machine can be found here: [2]

Pair Programming

If you would like to discuss or get to know the code, we have started pair programming and you are welcome to participate. This is more efficient and fun for coding, but it should be noted, that any important decisions and discussions, should be documented in the most relevant forum (the wiki, the mailinglists or in the code itself).

Please note your skypeid below if you would like to participate. Alternatively you can write to the dev mailing list and we can work something out.

  • mbarkhau (English/German)
  • fbarkhau (English/German)


User

A user can write messages, give scores to resources and write or edit resolutions. Each user has his own branch in the repository, which can also be accessed with the standard mercurial tools. The user may however only push to his own branch.

Registration is open to anybody, but over time the scoring system will allow users to increase their rank, so not all users are equal. Apart from displaying the recognition a user has gathered in the community the rank may be used to loosen certain restrictions on interacting with Metascore. Restrictions should only be imposed to prevent spam and abuse[1].

Group

A group can do everything a user can, with the difference, that the group may specify, that messages must be signed off by specific members or at a certain percentage of the group, before they are published. Ranks of the members may be aggregated by the scoring algorithms. A user may be a member of any number of groups. There may be a manifest associated with a group in which it may declare its purpose, principles etc.

Article

An article is stored in the repository as a single file. Articles are edited in the repositories of indivitdual users. The "main" branch contains only articles which were part of a proposal that was accepted and thus merged into the repository of the community.

Merging to the main repository is handled by Metascore, while the users have complete control over their own repositories. Articles should conform to a few guidelines, so they can be parsed by metascore. The should have a short name, which is used for their reference tag and contain a short introductory/summary paragraph, which may be displayed by the system, when the complete resolution is not appropriate.

Proposal

After editing an article, the changes reside in the repository of the editor. In order to become part of the main repository, the user must make a proposal, so that the community can evaluate the changes. The proposal starts with a review period, where the initial discussion takes place. After that, a the voting period starts, which gives all members of the community enough time to submit make their decisions. Once the voting period is finished, metascore evaluates the votes and determines if the proposal was accepted or rejected.

Vote

Although we advocate consensus over voting, for practical reasons, the prototype currently relies on voting to determine whether a proposal is accepted or rejected. Alternative solutions are highly

Interface

The following describes the layout and interface for displaying and interacting with the various resources.

A graphic designer would be nice, until then the design will be plain and functional. Some interactive elements will be enabled with fancy ajax and whatnot, for this we use the dojo toolkit.

For prospective development of the user interface, see PrototypeA/UserStories.

Score display

Should we display scores to the user. On the one hand, it might bias them, on the other hand it would offer them greater transparency of how the system is working. Certainly scores should be displayed, after the user has given a resource a score.

Messages

There are various pages to view the messages posted on metascore. The first view is the overview of current relevant[2] messages. Only title, author and submission date are shown for each message. Note that each message is considered by itself, that is a reply to another message will also show up here. Navigation among a thread can be done from any message in that thread. This should help give each message a fair amount of visibility, so that it can be scored.

Display of individual messages should be fairly obvious. Under each message are the tags that have been applied to it and (if logged in) a input for adding new tags. The message is parsed for potential tags.

Scoring

The specific interpretation of scores is yet to be determined, but the underlying storage mechanism will be the same, across the various algorithms, that use them.

A user may give a score to any of the resources described above. Scores are internally stored as a floating point number with a value between -1 and +1.

TODO: Algorithms

Tagging

The primary means of organizing the resources in metascore is through tags. While scores provide the mechanism to determine the value of a resource, tags provide information on what attributes apply to a resource. Tags are the primary means, for navigating content in Metascore.

Weight

Each time a tag is applied to a resource, a weight is associated with that tag. More precisely a weight is associated with the /application/ of that tag to a resource by a user. Multiple users may apply the same tag to the same resource but with different weights. The weight of a tag is determined by the order in which the user specified the group of tags for a resource. The sum of weights of this group of tags is 1. The distribution of the weights follow a power law with steepness 1.1.

Given n tags their relative weight will be:

y=f(x)=a*x^(-1.1)

if we have n values, the x will be = 1, 2, ..., n-1, n

with a = 1/ ( 1^(-1.1)+ 2^(-1.1)+ 3^(-1.1)+... ...+(n-1)^(-1.1)+n^(-1.1) )

When we then substitute the a in the f(x) and we calculate the y for each value of x equal (1,2,3,...,n-1,n) we should get a series of points that approximate a power law such that the f(1)+f(2)+f(3)+... ...+f(n-1)+f(n) = 1

Self Hosting

Once repository interaction is possible, we will start using metascore to develop itself: hosting the code of metascore in the repository it operates upon. A stable branch will contain the code that runs on the server, while development continues on user branches. Changesets approved by the community will be merged into the stable branch.

Future Development

The aforementioned functions are the basic functions we intend to implement for version 1.0. The following are features, which aren't essential to the project for now, but may greatly increase the usability of the website. Feel free to add feature requests here.

  • All pages should be accessible and usable via a mobile web browser.
  • While the page may make use of javascript, it should not be required.
  • RSS feeds for tags (lists resources to which a tag is applied)
  • RSS feeds to all events in the life cycle of a resolution
  • messages to discussions in which the user participates will be sent regardless of subscription
  • Participation via e-mail

Development archives

See also


Cite error: <ref> tags exist, but no <references/> tag was found
Personal tools