Brickwiki talk:Conventions/extraPage1

From Brickwiki
Jump to: navigation, search

Contents

EXTRA PAGE FOR CONVENTIONS TALK

This page contains material moved from BrickWiki talk:conventions in order to bring the size of that page beneath the 32k threshold. It is not intended as a 'second tier' information page and should be freely edited as the main page would.

Requests for Deletion

This isn't a debate; its just a note that you can discuss pages that you want removed on the page BrickWiki:Requests_for_deletion (posted by V)

See also the category Deletable things and the template Delete ++Lar 14:09, September 28, 2005 (Eastern Daylight Time)

Copying vs. Moving

I would like to suggest that when talk about conventions, open issues, questions etc, is taken to a new page, such as this one, that the talk text be moved, rather than copied, and a link to the relevant section be given in its place where it came from. Else conversations may still happen in multiple places when people don't realise that the thing got moved (much of the text above is tagged as copied... is it copied?). I suggest this as a convention in its own right. ++Lar 22 July 2005 18:26 (Eastern Daylight Time)

Good idea. Would have got to it but I see you already have. --Tim 22 July 2005 18:30 (Eastern Daylight Time)
not me, I moved nothing! ++Lar

Documenting colors

Moved to BrickWiki talk:Conventions/Colour where future colour discussion can go. Tim 10:29, 14 September 2005 (Eastern Daylight Time) PS. It's a discussion so we don't need to be consistent with spelling :P

Images

Image Formatting

I think a standard way to present images is goodness. Bare images like the above are not so great, in my view. Images should have borders, captions and hovertext, and should be positioned so that text flows around them. This can all be achieved with parameters to the image invocation. See Suspension Bridges for example. If people agree, I'll work up some proposed guidelines (Edit: Forgot to sign this but it was earlier today ++Lar 24 July 2005 19:47 (Eastern Daylight Time))

Image Attribution and hosting

The images in the LUGNET guide are all claimed to be owned by LEGO rather than copyrighted by LUGNET. How do we feel about using these images as is? LUGNET does not prevent people from using them, it just asks that LUGNET not host them, that is, that a copy be taken. Perhaps blanket permission from LEGO should be sought, and proper attribution given when the image is used (see above on Image Formatting) in the caption. Also do we have bandwidth to host a lot of images? Do we need to? I still haven't seen an example of an external image work so maybe we do? ++Lar 24 July 2005 08:58 (Eastern Daylight Time)

[[Template:lugnet image]] reading something like: "This image was originally hosted on Lugnet. LEGO claims ownership of it." --Astronouth7303 27 July 2005 22:36 (Eastern Daylight Time)
How about [[Template:externalSourcedImage]] with the "originaly hosted on" a parameter so it can say whatever site you want... Has anyone actually asked LEGO, Suz, Dan, etc about using their images and getting permission???++Lar 29 July 2005 00:52 (Eastern Daylight Time)
I'd hate to argue over such a small detail, but here goes. By use a general template in the image pages, it allows users to pick whatever. If we have [[Template:lugnet image]], [[Template:ldraw.org image]], it's easier to categorize them. (We can have {{external image|<url>}} for non-standard sources.) (I go for all lower template names so it's easier to type, no camelCase. Spaces work just as well.)
Gotcha. That works for me, set it up that way if you like. ++Lar 29 July 2005 14:18 (Eastern Daylight Time)
Let me recant part of the above agreement. As a programmer, I like camelCase or underscore_linking for things that I think of as variables or directives/functions etc, because spaces choke tokenizers and compilers, that's what I always learned and it's habitual. So I'd prefer that all templates use one or the other, but not spaces. Note that all (unless I missed one) the real templates we've created so far use camelCase (which is what Wikipedia uses IIRC), with initial letter capitalized. So initial letter capitalized CamelCase for template names is therefore my preference. Having some of each makes it harder to remember what the name is and requires you to go look up the template before you use it, even if you remember the basic name. Is that ok? ++Lar 11:13, August 26, 2005 (Eastern Daylight Time)
I prefer CamelCase too. I see template as 'functions' and with 'variables' and would prefer to use a system I am used to under these circumstances. Tim 12:23, 26 August 2005 (Eastern Daylight Time)

Archival of talk

Wikipedia (I gather) has a community norm that one does not delete talk but rather that one archives it by creating a subpage and putting in a link. Tim just deleted some talk from LDraw unit saying it was obsolete and inviting revert if anyone disagreed. It was, more or less. The larger question is, shold we adopt that policy/norm? It is an implication of the larger norm that one hsould not delete the talk of others (although editing articles without mercy is fine) ... these norms may not be correctly interpeted by me.

Archiving seems like more work than deleting but may have value. Thoughts?

Hi Lar, I did wonder about this: I thought that if every little bit of old converesation was left, pages would become full very quickly but also realised that deleting others posts could be rude (hence the revert comment). It might be nice to have an archive page which is just a huge bunch of categories with all old material on it. I don't really mind either way. Tim 26 July 2005 12:48 (Eastern Daylight Time)
People boil non controversial threads down to leave a summary of what was said and who said it and what the resolution was without the back and forth making it longer. But they also move longish stuff to an archive page, which is a page with a slash in the path (never created one so not totally sure of the syntax). In this case maybe the deletion is no big deal for you or me, we got to an agreement and implemented it, but for historical reasons should we save it? I don't think one big archive page for ALL talk is the way to go, but rather something per main talk page ++Lar 26 July 2005 18:44 (Eastern Daylight Time)
I think that we should archive all talk on this page - we have no realistic space limitation and it is very easy to make archives of talk per topic, eg. Spelling. It would be interesting for people to see how we came up with all our conventions a few years from now, no? --Venkatesh 11:35:00, 2005-08-02 (Eastern Daylight Time)
Agreed. Presumably all discussion eventually migrates to Brickwiki:Conventions/Closed Debates right? (because we eventually settle everything! LOL... so don't forget to vote on stuff up for votes everyone) If that gets too big then I guess eventually it can have [[Brickwiki:Conventions/Closed Debates/Archive1]] 2, 3, etc... What about archives elsewhere? Do we need a standard naming convention? ../ArchiveN seems to work well enough doesn't it? ++Lar 11:55, 2 August 2005 (Eastern Daylight Time)

Categories

Less is more

I've just posted this elsewhere (in a more specific context). I think that too many categories is just a pain in the rear end. Its too easy to forget where something goes etc. Maybe if we got to Wikipedia size it would become more important but if that day comes, stuff can always be sorted into subcats anyway. That is the joy of wikis. See Category talk:LUGs for an example of where simplification could help, not hinder. That's my addition to the topic anyway. Tim 26 July 2005 18:50 (Eastern Daylight Time)

K, with respect to the specific example, orgs/groups/clubs/lugs etc I think we are trying to use categories as attributes. Let's try a box! I will work up an example later tonite, but suppose we put all gaggles of people in ONE category, call it Organizations, and then have a template OrgBox... that box carries all the other info... does it have a web presence? What is the URL? Does it offer services? What kinds? Does it offer information? what kinds? Does it have members? Do you have to pay? Does it have discussion? can anyone read? Is it geographical or world wide? Etc Etc.... thoughts? ++Lar 26 July 2005 20:22 (Eastern Daylight Time)

OrgTypeBox and cats vs attributes

K... I did up a box template:OrgTypeBox and applied it to the following groups/orgs/resources:

I was going to change all their categories to just one, but got stuck on which one. What one name fits all of those? Not LUG. Not Community, not Resource, not Commerce... maybe just "Fan Groups" or just Organizations?

So what do you think? I think the box helps make the organization info clearer. What's missing? And what color should I use instead of that green, I don't like it... so far blue for connections, yellow (like the original LEGOLAND boxes!) for themes and green for groups. Now, off to bed for me... ++Lar 27 July 2005 00:04 (Eastern Daylight Time)

This is a much better system. I think you are right about categories being used as attributes. Categories are things which a user of BrickWiki would look at to see whats around. If an item is in multiple categories they should be quite different eg. Legoland Windsow could appear under category Theme Park and category Europe (if decide to add regional categories which I'm quite a big fan of as it means an interested user can find out whats going on in their part of the world). Tim 27 July 2005 03:19 (Eastern Daylight Time)
cool. I agree about multiple categories being wildly different and think regionals would be great. Now, then, the question on orgs is, what one word is the right word that coers them all???? organizations? Taking this implication to themes then,, shold we put all themes in "themes" and use the themebox once we get it fixed colorwise, to show hierarchy among themes? ++Lar 27 July 2005 07:46 (Eastern Daylight Time) (thinking of changing my handle to "boxMan"!!! LOL
I think that it is a good general approach. Themes would have additional 'Official/Unofficial', 'Related themes' (to cover parents, daughters and siblings etc., in fact I think this is already there) etc. Hierarchy doesn't really tell us much often and can be confusing (like SW/Space or Trains,Town/World City), I think relations are better. Tim 27 July 2005 08:15 (Eastern Daylight Time) (I think if anyone deserves boxMan it is Lar)
Yes, the template:ThemeTypeBox has "fan created" to catch official/unoff and it has parent theme and subtheme for hierarchy. It needs related themes (allies/adversaries) yet. So then, do we put all themes in category Theme and dump "Space", "Castle" etc as themes??? as for clubs/groups/orgs/services, I thought of "entities" as the master single category name, how would that be? Or should it be organization? ++Lar 27 July 2005 08:38 (Eastern Daylight Time)(doesn't really WANT the handle boxMan just saying...!)
Thumbs up for the themes. I think we should drop subthemes. If someone wants to know what subthemes space has they can just click on Space. While I agree that 'Entities' is more accurate, I think 'Organisations' is better as it is more obvious. Can we crosslink Category:Organisations and Category:Organizations? If not, we may want to think of a spelling neutral version or end up with two. Tim 27 July 2005 08:43 (Eastern Daylight Time)
Too bad category redirects don't work, we could just redirect 'sations to 'zations. Entities IS too estoteric I guess. How about Fan Groups? It's not completely accurate but it's third best (after Orgs which is second). I'd say "Orgs" instead of Organizations but not sure about using abbreviations. We may need our first "cleanup project" list to get all the themes squared away, they are all over the map now. However, fair warning, by dropping subthemeing we have to warn the user that they need to edit the space article to add the subtheme to the box parms (or we have to get it right ourselves or do a bot or something...) That's not to say it's not the way to go, just somehting to keep in mind ++Lar 27 July 2005 09:02 (Eastern Daylight Time)
If we get in now it won't be too much effort. I think Fan Groups is the way to go. It's quite obvious, accurat(ish) and spelling neutral. Tim 27 July 2005 09:10 (Eastern Daylight Time)
Call them COPs (Collection Of People) and then make a CopBox. --Astronouth7303 27 July 2005 22:42 (Eastern Daylight Time)
Not so keen on cops. It's an affectation. I think Fan Groups or Orgs or Organizations are all better choices. Maybe a vote? ++Lar 28 July 2005 10:25 (Eastern Daylight Time)

move completed

Based on the consensus (5-0 if we used resources) I just decided to Be Bold and cranked out the changes. The few items like BS, BL, fibblesnork etc were placed in Resources category and all the rest moved to category:Fan groups. Where I remembered, I also added a template:OrgTypeBox. I also flagged all the categories newly orphaned for deletion by putting in a template:delete (which takes one parm, NewPage, to say where content was moved). Where there was content on the category I moved it to an article of the same name (except singular instead of plural). Whew. It went fast though. Any questions, comments, errors, please raise them here, or on my talk page or whatever... ++Lar 12:30, 5 August 2005 (Eastern Daylight Time)

Further proposal for peoplish stuff

Dear all, in light of the direction of the recent vote on subcategorising, I would like to propose that we put category:Fan groups, category:Resources, category:Community debates, category:Running jokes and category:People all as subcategories of [[:category:Community and resources]] (suggestions for a better name are more than welcome) which would be linked to from the main menu. This seems like a good way to avoid clutter on the main menu whilst joining a collection of related categories together. I would like category:terms to be added to this as well as left where it is too. Please let me know what you think. Tim 12:20, 12 August 2005 (Eastern Daylight Time)

This proposal went quite a while with no further comment. Is it obviously a good idea? Not needed? I read through it and was opposed, but wasn't very worked up about it at all... but then I have been busy with LDD and LEGO Factory related articles... maybe do it and see who complains? But I have to say I'm not so keen, "Community and Resources" seems really contrived, especially for "Running Jokes" and the like. ++Lar 12:08, September 1, 2005 (Eastern Daylight Time)

IsA versus HasA

From wikipedia:OOA&D1 knowledge and theory : IsA is a kind of relationship that tells you about inclusion of the item (inheritance of properties). A cat IsA mammal which IsA animal. HasA is a kind of relationship that tells you things about the item. A cat HasA tail and HasA bitter sense of humor. (you COULD do multiple inheritance so that both Lizard (IsA reptile) and Cat IsA TailCarryingAnimal but that tends to be frowned on in the OOA&D community)

last nite, driving back from Indiana, thinking about a build problem, I realised that it would be really NICE to be able to ask "what parts use hollow studs" and get a list of all parts that do have hollow stud. The partbox, if we did one at some point, could carry that info, but it is categories that are the mechanism for carrying that info and making it easily searchable/listable. No current parts catalog has that ability, by the way, at least not directly. You can search on keywords or name fragments but you have to KNOW that 2finger-3finger plate hinges have hollow studs, it's not in their name to find by looking up name fragments. (not generally I mean)

So a place where I would argue for a lot of categories (IF BrickWiki was a comprehensive catalog of all parts, at some future point, and I am NOT convinced it should be, but if it were) would be to model HasA. That's something to toss out there and think about. It's a counter argument to the 'let's not have a lot of different categories' which I DO agree with for the most part... especially when talking about IsA... I tossed it out here because there hasn't been much reply to my call for long term strategy discussion here: BrickWiki talk:Open Questions#Comprehensive goal regarding parts/sets ++Lar 28 July 2005 12:16 (Eastern Daylight Time)

At this point in time, I feel we shouldn't flood BrickWiki with part articles. (Except parts like the jumper plate, which have special significance.) However, such an index would be handy. (The best you could do is scan the parts library for parts using a certain primitive.) Maybe we can start the "parts" subwiki for that. --Astronouth7303 29 July 2005 13:27 (Eastern Daylight Time)
Agreed. Or flood with renders either. It's a lot of space to take up. So, is there a nifty way to determine a part (that got added because it was special) that doesn't have a render already embedded? That might be a thing for a bot... Hmm. I better get writing. (first I think we need a Part box to capture stuff like history, connection systems it participates in, special notes like not made from ABS, etc...) Thoughts? ++Lar 10:58, 1 August 2005 (Eastern Daylight Time)

1 - not really a very good article, there are lots better out there.

Plurality

I just noticed that we have some categories that are singular and some that are plural.. see Special:Categories Should we have a convention? Should most things be plural (fan groups for example, and regions and connection types etc)? That's the way it feels. There are a few singular things (menu, color, learning). Do these all make sense? Just wondering (thought of it because of the creation of Fan groups vote) ++Lar 13:42, 1 August 2005 (Eastern Daylight Time)

I'd been wondering about this but figured we haven't had any problems yet. I notice Wikipedia are against plurals which makes sense in their case but I think pluralising is fine (and indeed more sensible) as long as the thing will ALWAYS be used in the plural form. Not really helpful I guess. Tim 14:35, 1 August 2005 (Eastern Daylight Time)
I think most of our categories are plural. Further I think wikipedia categories mostly seem to be plural too... In fact I had one that was singular just now and changed it at some effort. So I suggest that we make the guideline that they should be plural unless clearly there is some reason not to (can anyone provide an example where it doesn't make sense???) ++Lar 12:12, September 1, 2005 (Eastern Daylight Time)
Agree. Wait one week and if no complaints, add it ;) Tim 13:21, 1 September 2005 (Eastern Daylight Time)

What about just archiving it in the normal way?

called ../archive_01 ../archive_02 or the like? Most of the conventions have come to rest now I think. ExtraPage is confusing. ++Lar: t/c 11:59, March 11, 2006 (Eastern Standard Time)

I decided not to do that because it is not so much an archive as stuff that should be on the main page but doesn't fit (slightly different IMO). If you would prefer to make it an archive then feel free to move it. It almost was at first until I changed my mind so I'm very indifferent. Tim 12:56, 11 March 2006 (Eastern Standard Time)
not that sussed either way so... whatever works. As long as people know what is what and where to find it.
Personal tools