home |
MusicMoz's goal is to produce the most comprehensive database of music online by relying on a vast army of volunteer editors. MusicMoz is an online community. Thus, it is important to have the ability to work well with other editors, in addition to having a critical eye for organisation and creativity.
The goal of editors should be to produce useful micro-music resources for the web public.
As a new and developing project, new features, improvements, and changes are happening on a regular basis. Such changes will be announced in the editor forum, major changes will also be announced on a dashboard note. Editors' opinions are extremely valuable, and editors are encouraged to post suggestions in the forums.
Being careful to follow copyright law is of the utmost importance to this project. Copyright issues at MusicMoz can be conveniently divided up into three types.
As part of becoming an editor, you agree to assign to the Open Music Project the copyright to any material that you have created for, or submitted to, MusicMoz, as well as any such material that you will create or submit in the future. In return, MusicMoz grants back to you a non-exclusive, royalty-free right to use any material that you have or will have created or submitted to MusicMoz. Additionally, you warrant that you have necessary rights to authorise the distribution or redistribution of any material you have created or submitted. Furthermore, you will provide any information that the Open Music Project reasonably requests relating to claims that material you have submitted to MusicMoz infringes on the rights of a third party, should it become necessary.
By submitting material to the Open Music Project, outside users agree to grant MusicMoz a non-exclusive, royalty-free rights to use, publish, redistribute, edit, modify, or create derivative works from their submission. Furthermore they warrant that the have the necessary authority to grant such rights. Editors working with these submissions should be aware of this make a reasonable effort to verify such authority.
Editors should not upload or display images unless they have permission to do so from the copyright holder. It is acceptable to upload album covers, since explicit permission does not need to be obtained to use these.
Content must not be copied from other websites or any other source unless permission is obtained. Non-exclusive, royalty-free permission must be granted for MusicMoz to use, edit, modify, create derivative works and redistribute this content under the MusicMoz Data Use License. This includes biographies and reviews. It is, of course, allowable for editors to list factual information, for example track listings, and to obtain this information from other websites without seeking permission.
Any correspondence between editors and outside copyright holders for the purposes of obtaining permission should be cc:ed to MusicMoz staff for archival purposes. Editors should identify themselves as volunteer editors of the Project to copyright holders acting on behalf of MusicMoz. All copyright agreements must be approved by staff before the affected content can be added to the Project.
As a special case of the situation mentioned above, the Open Music Project makes use of Open Directory Project data under the terms of the Open Directory License. As part of these terms, any MusicMoz category containing data from the ODP must display ODP attribution. This attribution can be turned on or off by metas and staff on a category by category basis.
There are currently three types of editors: Category Editors, Editalls, and Meta Editors, each of whom work with staff and the rest of the community to further the goals of the Open Music Project.
Category Editors are editors who only edit those categories (and their subcategories) in which they are listed editor. This group makes up the majority of the MusicMoz community. All new editors start out as category editors. New category permissions may be requested using the New Permissions Request Form and the New Category Creation Request Form. The guidelines for category editors are contained in this document.
Editall allows an editor to:
The role of an editall is to provide quality control, editorial integrity, clean, intuitive taxonomy and overall consistency throughout the Project. Editall is granted to certain editors who have displayed a good grasp of MusicMoz's guidelines and purpose, and good editing skills. We encourage all editors to aspire to editall permission.
In addition to the guidelines outlined here, Editalls must also adhere to the Editall Guidelines.
Meta Editors, along with all the editall permissions, have the ability to accept and reject new editor applications and applications for new permissions from existing editors, along with access to tools to support this task. They can also turn off the submit URL and become an editor links on categories, as well as ODP attribution.
The role of a Meta Editor is a leader and community manager for the Project. As a group, the Meta Editors govern the MusicMoz community. They work with staff and the community to develop guidelines and codes of conduct for the community and shape the growth of the Project. Meta is granted to a few seasoned editors who show exceptional editing, leadership and communication skills, as well as a fundamental understanding of the Open Music Project's goals and purpose.
In addition to the guidelines outlined here, and the Editall Guidelines, Meta Editors must also follow the Meta Guidelines.
Editors are allowed to use HTML in textual material such as articles, biographies, reviews, etc. HTML should not be used in URL objects. HTML should be used sparingly, for emphasis, formatting, hyperlinking, and including appropriate pictures in textual content and category descriptions. Javascript, CSS, font tags, colour schemes, Flash, Java, and animated content are not permitted. All HTML should be standards compliant; browser specific tags are not allowed.
Since HTML is allowed, you must remember to use the <p> tag to start a new paragraph, and to express < and > as < and > respectively.
Dates should be entered in yyyy.mm.dd format, e.g. 2002.10.31. When partial dates are known, these can be entered using the formats yyyy.mm or yyyy.
Dates entered in this format will sort correctly, where applicable, and will be displayed in a standard format, e.g. 31st October, 2002.
Each category may have up to two cooled objects in it. Cooling moves an object to the top of the listings, and in the case of URLs, also bolds it.
It is inappropriate to:
You must supply a reason for every cooling or uncooling.
In addition to the number of sites in a category and the number of unreviewed submissions, you may also notice, from time to time, that there are a number of "Fish" in the categories in which you edit.
At the Open Music Project, a Fish refers to any unreviewed submission that is not an URL, including, but not limited to articles, releases, reviews, and suggestions. These types of unreviewed submissions are highlighted to assist editors in finding them. The practice of hunting down these Fish and publishing them is known, endearingly, as fishing. Fish have no other special feature.
We encourage editors to prioritise the preparation of these sorts of submissions for publication above the reviewing of URL submissions because it is the collection and publication of these sorts of data that is a focus for the Open Music Project. URL submissions can be brought in from the Open Directory Project, and therefore are not necessarily unique to our dataset. These Fish represent content unique to MusicMoz.
From time to time users will submit Suggestion Items with potential corrections or improvements to the MusicMoz dataset. If you find one of these, you should try to act upon it in a timely manner, as the Open Music Project exists primarily as a resource to its users. Always be sure to verify the data before incorporating them into the project.
Occasionally submitters will submit content in a Suggestion Item rather
than the proper informational item. In these cases, you should copy the
submitted information into an object of the correct type. At no time
should Suggestion Items be published.
The Open Music Project, like the Open Directory Project after which it has been modelled, uses a hierarchical category system to organise its data. Taxonomy and ontology are words used to refer to the work of organising these categories. The goal of any such categorical classification system is to aid the user in finding material.
MusicMoz follows a peer review process. No one editor owns a category and, even if you are the only editor listed in a category, other editors will still be able to edit in that category. These include parent category editors, editalls, meta editors and staff.
In such a system, communication is critical to successful editing. When you make changes that affect how the data are organised, such as creating new categories, or moving items from one category to another, you should communicate these changes to the rest of the editing community before the changes are made. This remains true even when you are the only editor in a given category or branch.
New category permissions can be requested by using the New Permissions Request Form. These requests are reviewed by Meta Editors and staff and granted based on merit, past editing experience at the Project and knowledge of the subject. When you apply, the quality of your current categories and your edit history will be evaluated. To be eligible for new permissions you should have demonstrated, as appropriate to your current categories, the ability to:
The size of the categories for which you are eligible to be approved for, vary with your editing experience. New editors should look for smaller categories to build up first, before requesting editing permissions in larger branches.
Please observe the following points when asking for new permissions:
When a category gets too large, subcategorisation can be useful to help users find the information they want. In general, for categories outside of the Regional branch, you should subcategorise data by topic whenever possible. If topical subcategorisation is not possible, you may then attempt to organise by geographic area or by using an alphabet bar, however this should be avoided whenever possible.
Various branches of the Project may have their own rules for subcategorisation. Consult the Branch Specific Guidelines before subcategorising to see if this is the case in your instance.
All editors may make subcategories in the categories for which they have editing permissions. You will automatically have editing permissions in this new subcategory and it is not necessary nor recommended that you list yourself as an editor in the new subcategory. Leaving smaller categories without listed editors encourages new editors to apply and current editors to pick up new permissions elsewhere in the Project.
In addition to creating subcategories within categories for which you already have editing permissions, it is also possible to request the creation of a subcategory which you wish to edit elsewhere in the Project hierarchy. To do this use the New Category Creation Request Form which is linked from your editor dashboard as Request the creation of a new category. If your request is granted, a Meta Editor will create the new subcategory and give you permissions to edit within that subcategory. This form should not be used to request the creation of categories which you can create yourself. The following points should be observed when filling out this form:
Please remember that applying for a new category does not necessarily mean that you will be approved for it. As with new permission requests, the state of the categories you already have will be a primary indicator to the Meta looking at your request as to the suitability of your application. Be sure that your current categories are in good shape and guidelines compliant.
The Open Music Project does not use a standard thesaurus of category names, however, certain guidelines do exist for naming subcategories. The Preferred Terms should be used, whenever it is reasonable to do so. Various branches also have their own guidelines on naming subcategories. Check the Branch Specific Guidelines to see if this is the case for you new category.
Category names:
From time to time you will find it necessary or convenient to move or rename a category which you edit in order to better organise the Project's data or to make the taxonomy more intuitive to the end user. A special tool called Category Move, or catmv, exists for the purposes of moving and renaming categories. All categories must be moved and renamed using this tool. It is never appropriate to move or rename a category by creating it in the new location or with the new name, moving all the content from the old category into the new one and then deleting the old category.
Catmv is only available to editall and meta editors since its uninformed use has the potential to do great damage to our dataset. Category editors can request a category be moved or renamed by posting their request in the appropriate thread in the Ontology forum. Except for minor fixes, all category moves and renames should be discussed in the forums and consensus reached before being carried out. All editors in the affected category branches must be notified of the proposed change. No changes will be made until all affected editors have been notified. For more information, see the section on category moves and renames in the Editall Guidelines.
In hierarchies which contain content in addition to links, such as Bands and Artists, all links should be placed in Links subcategories.
Links are a special type of object, and adding them is slightly different. Instead of the usual method, put the URL you want to add in the "Add URL" box, and click the corresponding add button. The advantage of this method is that if the URL is listed in any categories already these will be displayed to you.
Listing appropriate deeplinks is strongly encouraged, when those deeplinks contain useful and relevant information.
Certain types of URL should not be listed:
MusicMoz uses the ODP guidelines for site descriptions. For those unfamiliar with these guidelines, they are available at http://dmoz.org/guidelines/describing.html. You do not need to be an ODP editor to access this document.
There is an option on the edit page, "Synchronise with an ODP category", which allows you to carry over any changes from a corresponding ODP category into the MusicMoz category. ODP data is free to use, providing attribution is displayed, so synchronising a category also adds this attribution, if it is not present. The synchronise feature offers a list of suggested changes when selected, and the editor can accept none, one, or any number of these changes.
ODP editors are strongly advised to make changes to the category in the ODP, then use the MusicMoz synchronise feature, since this updates both directories.
In branches where links appear along with other types of objects, all links should only be listed in Links/ subcategories. If you are unsure of whether you should be using a Links/ category or not, consult the appropriate Branch Specific Guidelines if they are present, or ask in the editor forums.
Submitted reviews which consist only of a rating with no text should not be accepted.
Articles, reviews, and textual content must not be copied from other sites without permission from the copyright owner of that content. Please see the section on copyright for more information.
Articles, reviews, and textual content should be written in good English, with proper capitalisation, punctuation, spelling, and grammar. Support for, and inclusion of, other languages is currently in development, but at this time, only English content should be incorporated in the live Project. Standard (British/Queen's) English and American English spelling and grammar is acceptable. This includes suitably similar English, for example Canadian or Australian variations.
As part of your editing duties, you may find it necessary to review, edit and publish textual material submitted by outside users. Please keep in mind the following guidelines when handling such material. Briefly stated, your goal as an editor is to bring submitted content into line with the guidelines stated above for appropriate English while not changing the tone or meaning of the text.
Things that should and should not be done include:
Editing textual material without changing its meaning or tone can be a difficult task. Editors are encouraged to utilise the editor forums to collaborate on preparing difficult texts for publication.
MusicMoz welcomes submitted content for outside users, and, as such dislikes refusing submitted articles. Articles should not be denied publication for the following reasons:
Articles may be refused publishing for the following reasons:
The decision to deny publication to a text should not be made lightly. Editors are encouraged to seek the opinion of other editors on the Project before making a final decision.
Images used on MusicMoz must be uploaded to MusicMoz. Do not link to or host images on other sites.
Do not upload any image without permission from the copyright holder, although album covers may be uploaded without gaining explicit permission. See the section on copyright for more information.
You can upload an image to MusicMoz by selecting the "Upload Image" link from your dashboard. Before uploading an image you should ensure the image meets these guidelines:
After uploading the image a preview is displayed, along with the URL of the uploaded image.
Select the "Manage Images" link on your dashboard to list, view, delete, and rename images you have uploaded.
Category graphics, the images that can appear at the bottom of any category, are handled differently to other images. You can set or change the image for a category by using the "[Change image]" link on the edit page. The set of available images is determined by staff. Editors may suggest additional images by e-mailing staff with a link to the image they want adding, along with a caption. Suggested images must be copyright free or the editor must hold the copyright.
Alphabet bars, or alphabars, provide a last resort of categorising items which cannot be broken down further by topic. They should be used sparingly since they are difficult for end-users to navigate. If you want to create an alphabar please ask in the forums to have it done, and a Editall or Meta Editor will do it for you, as doing it manually is time consuming and prone to error.
Also known as symlinks, @links point to categories that could serve as subcategories of the current category. Symlinks are distinguished with an @ at the end of the category name. There can be many @links in a single category. @links are mixed in with the subcategories.
@links should be used instead of having two categories for the same topic or sites.
Related category links point to categories that are sibling categories in other areas of the directory. There should be at most a few related categories in each subcategory.
It is common for a category to have a related category link to a category that @links to it.
Despite their reputation, newsgroups can, occasionally, be useful for finding information, asking questions, and discussing topics.
Only link to newsgroups that are publicly accessible. You can check if a group is public by looking on Google Groups.
Communication with other editors is a vital part of participating in this editing community. At all times, be considerate in your communications with other editors.
There are a number of forums for discussion of editing issues, along with a forum for non-editing topics.
You also can use the forum to communicate with the other editors in your category or categories higher up the hierarchy. One way to gather feedback from other editors is by creating a forum thread and then e-mailing your co-editors with the thread's URL, requesting that they reply in the thread. This way everyone can participate in the discussion. You may also get some very useful suggestions from editors who don't edit in your specific category, but just happened to be browsing the forums. We strongly encourage editors to feedback others regarding a forum topic if he/she wishes to solicit a lot of response or if the topic being discussed is a large-scale change that would affect a number of different editors (some editors don't read the forums regularly).
The available forums are:
More forums may be added in future if needed.
Posting to the Forums
For new posts:
When posting a reply to a thread:
Hypertext Links in Forums
If you are referring to a specific site, include the URL. If you type anything beginning with http://, the forum software will make everything from that until the next space or new line into a hypertext link. Readers can click on the link to see what you are referring to. However, this also means you don't want to type http://musicmoz.org, as that comma will be converted into part of the link, and will lead nowhere. Leave a space before and after any hyperlinks before punctuation.
If you are referring to a specific category enter it using slashes and underscores, like:
and the forum software will convert that to a hyperlink pointing to the appropriate category. If you enter your category paths using colons and spaces, eg. Bands and Artists: D: Davis, Miles, the category name will not be hyperlinked. As with URLs above, be sure to leave spaces before and after the category path. Category paths need at least one / in them to be recognised by the forum software, so if you want to refer to a top level category, be sure to include a trailing slash, like:If you wish to contact another editor directly, the way to do this is editor feedback.
To send an editor a feedback, go to their editor side profile, which you can access by using the "Find an Editor" link on your dashboard, or by clicking on the editor's name on an edit page or forum post, then select the "Send to <editor>" link.
From time to time members of the public may send you feedback, since there is a form for this. If you receive abusive feedback, advertising, or anything you think is inappropriate use of the feedback feature, please forward the e-mail, with headers, to MusicMoz staff.
An IRC channel is available for MusicMoz editors. If you have a suitable browser and IRC client, you can access this from the "IRC Channel" link on the dashboard.
Discussion of editing and non-editing issues is fine on this channel, please be considerate in your communication. This channel is not monitored by MusicMoz staff, although staff may participate in the channel.
You can contact an individual staff member by using editor feedback.
If you wish to contact staff, not an individual staff member, you can use the feedback form, also linked from the MusicMoz home page.
The content of the Editor Forum, Editors' Notes, and Editor-to-Editor E-mail and Feedback are private and intended only for internal use by MusicMoz editors. Editors may not publish or disclose quotes from these sources to anyone other than other current editors or MusicMoz staff. Rephrasing is allowed only if the communication as rephrased could not be attributed to a specific editor and disclosure would not violate any editor's expectation of privacy, with the understanding that a diplomatic choice of words is the rephraser's responsibility. It is never appropriate to disclose the identity or e-mail address of an editor without the consent of that editor.
Violation of MusicMoz e-mail or forum privacy will not be tolerated and is grounds for removal and possible legal action.
Staff may disclose the relevant contents of forum threads, e-mail, editor's notes, and other MusicMoz communications in legal matters involving MusicMoz. This means that the contents of the forum threads, including the private meta forum, as well as e-mail sent to staff, may be forwarded to legal representatives.
Editor accounts are assigned solely to the person who is listed on the application form. Accounts may not be shared with a relative, co-worker, or friend. Accounts are non-transferable. Accounts discovered to be used by anyone other than the person to which they were assigned may be disabled. Editor accounts are free; instead of using another's account please apply for your own.
Only one account is permitted per person. Former editors, whose accounts have been disabled, should email staff to ask for reactivation of their accounts rather than applying for a new account. Editors who are found to have more than one account, either active or inactive may have some or all of their accounts disabled, at the discretion of MusicMoz metas and staff.
It is MusicMoz policy not to change an editor's account name once it has been assigned.
In general, it is best not to do this. However, if you do forget your editor account password, you can request to have it sent to the email address we have for you on file by using the Password Reminder Form. If you have forgotten your password and you no longer have access to the email address we have on file for you, you may contact MusicMoz staff and we will consider your request. We reserve the right to refuse any emailed password requests.
Your account will remain active at the Open Music Project so long as you log in and remain active. After six months of inactivity, your account will be inactivated and a notice of this will be automatically emailed to the email account on file. You can ask for your account to be reinstated by sending your request to MusicMoz staff. If you were an editor in good standing at the time that your account was inactivated, you will likely be reinstated. If your account was revoked, or you had received warnings for poor or abusive editing, then we may decide not to reinstate your account. In all cases we reinstate editing privileges (in full or in part) at our sole discretion, and we may choose not to reinstate an expired account for any reason.
The Open Music Project reserves the right to terminate the account of any editor at our sole discretion, for any reason. In addition to the instances noted elsewhere in this document, reasons for removing an account include, but are not limited to:
The Open Music Project prides itself on being a free, non-commercial, open resource for the music community. We rely on the good will of our volunteer editors to select, review, edit and organise our data fairly and equitably, without bias. It is never acceptable for editors to accept or solicit any form of compensation for their participation in the Open Music Project and we also discourage submitters of content from soliciting or bribing editors in exchange for publication in the Project. Editors found to be accepting or soliciting bribes in exchange for publication of data or biased editing will be removed from the Project.
Everyone is welcome to apply to join MusicMoz, including those with vested interest in the music industry, or those who own, maintain and promote websites. Editors may have business or other types of affiliations relevant to the categories they edit, and may add their own sites or sites with which they are affiliated. However, it is contrary to the goals and policies of the Open Music Project to add only their own or affiliate sites, to engage in self-cooling or other forms of self promotion, to exclude or disadvantage sites belonging to competitors for the purpose of harming the competitor, or other biased editing. Inappropriate actions may include excluding competitors' sites from the directory, intentionally editing their titles or descriptions in a manner that distorts their content or diminishes the chance that users will find or view those sites.
In addition to the guidelines outlined here, supplementary guidelines have been drawn up for various parts of the Project. These supplementary guidelines are designed to help the co-ordinated development of those parts of MusicMoz with which they deal.
Branch specific guidelines exist for the following top level categories:
MusicMoz Staff reserves the right to change and/or update these guidelines at any time.
Although staff has the final say over the contents of the editing guidelines, suggestions from editors are very valuable.
For simple corrections, such as misspellings, an e-mail to staff is sufficient. Any larger changes, or suggested inclusions, should be discussed in the editor forums, and agreed on by editors, before being presented to staff.
Last updated 8 May, 2003 GMT by ketiltrout.
Copyright © 2001-2004 |