Subject:
|
OMR Submission and Storage
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Wed, 21 Jul 1999 05:17:42 GMT
|
Viewed:
|
855 times
|
| |
|
|
I feel that we should wrap up plans on OMR submission and storage so we can
get the structure in place to begin accepting models on the OMR itself.
First off, PLEASE DO NOT email me your submissions to the OMR. As of now I
am not officially accepting submissions and all they do is fill up my
mailbox [1].
So far, I gather that this is the plan (correct me if I'm wrong or have a
bad memory):
1) A Lugnet newsgroup (cad.dat.models.sets or cad.dat.models.omr) will
handle submissions. A user will post an MPD to the group, and it will also
handle replies to discuss that particular submission.
2) A model editor will pick the model up and check it against a
model/instructions, and format it to the OMR standard for files.
3) He/she can then package it as a zip/tarball (both?) with the proper
directory structure in place (under models/).
4) Somehow the file gets to Jacob or I, and it is uploaded to ldraw.org [2].
5) Somehow (I don't know how) there will be an automated update to the OMR
pages. I know we can't have a database on the server, so what is the
easiest way? I can't go in by hand and add one whenever it is added - its
just too much work. We need to get this so it is automated and requires
minimal human intervention. Suggestions?
So...
We also need to finalize submission rules. Digging up the archive, we have:
- Use of actual physical model strongly reccomended, use of instructions
required.
Ditto on this one.
- Submodels must reflect submodels in instructions or must reflect movable
part features on the model
But submodels which have no moveable parts -- should they be inlined or
included in the MPD? Pros/cons?
- If the element is available, it must be used. Replace unavailable decorated
elements with un-decorated version of that element
Should be no question here.
- Minifig accessories are required if available, not required if unavailable
- If there are any discrepancies in the model the author must submit an errors
list for the editors to take note of and to publish in the release of the
MPD
The proper format for the error notice is a comment line right after the
part in question.
- If a model exists in the repository, the same model by a different author
will not be accepted
This needs to be discussed. If someone else submits the same model with
less errors it should obviously be placed in the repository. Could there
be multiple entries for a model, with the accuracy of the model displayed
as a percentage (part lines total over part lines accurate)? So we could
have 2 x-wings - for example one submitted at 85% accuracy and another
submitted at 90% accuracy?
The thing is this should not become a personal thing. Favorites shouldn't
be played in the area of official models - if a model is accurate, add
it. If someone else comes along with a better model, replace it. We could
have multiple entries of the same model, but IMO that would just fill up
space. If someone modifies an existing model - what should be done with
the author name on the header? I feel it should reflect the most recent
author, the one who updated the model.
A log could be kept of the history of a particular set number in the OMR,
so we see that it was originally submitted by so and so on such and such,
updated by what's his name on someday, and updated by john doe on january
1st, etc... A simple log could look like this:
Updates for 7140 X-Wing Fighter:
7/20/99 - By: Tim Courtney - Approved for OMR by Ryan Dennett - 85% accurate
8/01/99 - By: Jeremy Sproat - Approved for OMR by Kevin Bane - 90% accurate
and so the first model gets replaced by the second, etc...
and of course this could be put into a table where things like date,
author, and approved by are in columns. It could be HTML and done this
way, or done like above in a txt file.
The key is automation here...
How should author discrepancies be handled? For example, someone submits a
model to the OMR as their own. It is approved and added. A while later
someone emails a model editor or myself claiming to be the true author of
the model with proof. What should be done? Should the author in violation
lose credibility? Obviously we should see if the true author would like to
keep the model in the OMR and change the author to him/her. This is
something that might happen - I have seen people claim others' models as
their own - it could happen on the OMR.
How should models with stickers be handled? (not screened on decorated
elements, actual sticky stickers) Some stickers span more than one
brick. Should it be packaged with the mpd in some way, shape, or form? It
doesn't seem like they quite fit in official updates, unless we get sticker
parts going and insert a sticker alone with no brick attached and place it
directly on top of other bricks.
A lot of these questions and this information is needed to create an OMR
model creation/submission guide for ldraw.org. It is also needed to get
the infrastructure of the OMR in working order. I would place this area of
the site on top priority for now. It is one of the areas with room for the
most growth and one of the most useful areas of the site for
users. Obviously, reference is a strong second to this.
[1] Well, I did create an OMR folder to hold all the submissions I have
gotten so far, but please don't send any more.
[2] We could instead have an OMR management system where editors have
usernames and passwords and may manage files within the OMR itself via
their web browser. Is it big enough to do that? How hard would such a
system be to make? Would anyone be willing to code it?
-Tim Courtney
ldraw.org Project Coordinator
http://www.ldraw.org
http://www.zacktron.com
AIM: timcourtne
ICQ: 23951114
|
|
Message has 2 Replies:
 | | Re: OMR Submission and Storage
|
| Tim Courtney <tim@zacktron.com> wrote in message news:4.2.0.58.199907...omm.com... (...) We might as well use models.sets for this, and just have authors include "OMR" in the subject header. This will avoid the confusion that would come with two (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
| | | Re: OMR Submission and Storage
|
| (...) Though 'OMR' would denote a submission to the OMR, etc, it would be better to have a separate group so there is absolutely no question what is a submission and what is not. All we need is for an editor to pick up a non-submitted model that (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
|
34 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
