Brickwiki talk:Open Questions

From Brickwiki
(Redirected from Brickwiki:Open Questions)
Jump to: navigation, search

In May the contents of this page at that time were moved to an Archive subpage for reference.

Contents

Please start new discussions (or reopen old ones) on this page.

Actions to be taken (if any) when a question is closed can be added to the To-do list.


A clear Brickwiki vision

Brickwiki needs a clear vision of what it is and isn't. I believe it should not try to do what other web sites are already doing well. (I am probably going to steal some words from Lar and Venkatesh; apologies.)

  • It should help newbies and experts find introductory material to LEGO topics of interest to them. I.e. it should be a *guide* to LEGOdom.
  • It should help newbies and experts find resources to dig deeper into those topics. I.e. it should be a *gateway* to LEGOdom.
  • I believe it should be an encylopedia for what I refer to as LEGO technology: our collective knowledge of what we can do with LEGO elements.
  • I believe it should be an encylopedia for what I refer to as LEGO culture: our collective experience of the significant things we have done with LEGO elements.

Looking back over this very talk page, this largely treads trodden ground. However, some things have changed, so it's probably worth thinking about. My most important point is that we need a tag line, a clear vision, a [gasp] brand.

Something like: Brickwiki: a guide and gateway to the LEGO collective. --ALittleSlow

Exactly! Thanks for bulletizing some of my rambles on the "mailing list" ++Lar: t/
We should make this the start of a new "Open Questions" page. Tedward
OK by me. It's a great summary actually to put some other places... ++Lar: t/
One of those places, in my view, is Brickwiki:What_BrickWiki_is_not which really needs updating. ++Lar: t/
Done. --ALittleSlow

Reboot

I would like to propose that we archive the entire content of this page and the Article Request page and start fresh. Tedward

Yep. Probably a task for someone would be to implement a convention for naming archive pages, and an archive template to let you find them easily ... Wikipedia often has a box at the top of a page listing the current archives with links. ... not following you on the request page, it appears to be a red link? ++Lar: t/
Wikipedia proposes three solutions: . I'm leaning toward the "move" method, but I am ill-informed, at best. --ALittleSlow
I favor copy and delete because that keeps the history of the original page in one place, although there are some that argue that having the revision history move with the chunk of discussion is better. BUT copy and delete lets you keep some of the page around when you don't want to archive the whole page. Such as, for example this section. ++Lar: t/

Merging Article Request pages

I would like to merge the Article Requests Page into the Project page as this seems logical to me. Any thoughts? Tedward

They seem kinda different to me... Projects are possibly across several articles. (Suppose the set/set2 thing gets done, we might need a 'project' to clean up all the current usages or ...) but maybe? ++Lar: t/


Testing ConfirmAccounts

I have approved ALS Test... see if that works. Can someone create another one I can reject to test that out too? I think we may want to change the permissions setting to allow admins to do this, instead of requiring a 'crat, what do others think? ++Lar: t/

In the absence of contrary opinions, and with the goal of approval legitimate accounts as quickly as possible, I have given admins ConfirmAccount permission. We still need to tweak the E-mail messages and BW E-mail address(es) --ALittleSlow

Governance and Organization

Though I might as well open this can. The basic question: how do we make decisions? There was originally some talk at Organization and Convention voting convention still OK?. But I couldn't find anything substantive more recently. To help make the problem more tractable, I suggest these subquestions:

  1. What are the (social) rules by which we make decisions? (For example, what constitutes a quorum?)
  2. What are the (wiki) mechanisms by which we make decisions?
  3. What are the mechanisms by which we document these decisions?
  4. Where should the rules and mechanisms be documented, at least at a high level?

And some thoughts on these:

  1. I don't have good thoughts on the first question.
  2. We have a few in place: there's the Call_for_votes template, and there's Requests_for_adminship, and of course Brickwiki talk:Open Questions.
  3. We have a good template (in the general sense) for doing that with Open Questions.
  4. Organization?, Conventions?

--ALittleSlow

Big wikis tend to want to have everything decided by consensus. Which is fine, when it works, but we're small and sometimes things need to be decided quickly, and we could spin a lot of wheels trying to decide what a quorum and what a consensus are while pressing decisions go undecied. Ad hoc, since the restart, you and I (with input from Ted) have been driving a fair few decisions. This made sense for the relaunch, since you and I contributed the hosting cost. I actually think that model might be good... those who pay get more say. If someone wants a vote, let them chip in a year of hosting. (Venkatesh gets an "emeritus" vote or something since he contributed so much in the beginning)
That may not be a very popular view but there you have it. I think we need to decide how to decide first, before worrying about how to document it. That's less fundamental, in my view, than the first point. ++Lar: t/
I agree that deciding how to decide is the top priority. Pay to play risks alienating the people we need to be successful: editors. Plus we don't need money immediately, so there's little need for someone to pay in. I agree the value of being nimble, though, too. How about this: decisions are made by a consensus of active admins after a period of open discussion. Of course this is what we are doing now. Practically, this puts decisions in the same group as you just mentioned, but leaves the door open for other forms of contribution. --ALittleSlow
I think that sums it up nicely. "active admins" gives us a little flexibility and enough clarity, I hope, for newcomers to figure out. Tedward
I'm willing to also recognise significant editorial/content contribution, I just want to avoid someone trolling in with 20 edits or whatever and saying they get a say. Ted, for example, ought to have a say whether he pays for hosting or not. Ditto Tim G. I think. Some concrete in the definition of "active" is probably helpful. ++Lar: t/

Comments on models

(Outdent) I'd be happy with any of the models suggested above (but note that my opinion doesn't matter if the 'pay for vote' or 'active admin' models are suggested). As an aside, I thank Lar and ALittleSlow who have paid for hosting for the current incarnation of Brickwiki. This was a surprise to me, as was the involvement of Jer in the incarnation; I suggest that it would be worthwhile having this recent history set out somewhere convenient.

Hey Claude, I did try to make a start at the recent history on Brickwiki:History_of_Brickwiki. Re: this whole discussion, I think we need to focus on contributions to BW as a criteria. Whether that is $$ for site or editing/admin work all should be valued and recognized. Frankly I think that anyone who has admin status has been accepted into whatever group should have the power to make decisions and interpret consensus. I think that group (trustees, governance committee, board of directors, whatever) should also include editors/contributors who choose not to become admins but otherwise would be nominated and accepted as admins. Everyone who has made a contribution, large or small should have a right to make their opinions known but it should be the group that makes the decisions. Tedward
Thanks for pointing out the history - I had missed that. I phrased my comment "...my opinion doesn't matter..." above poorly: I am sure my opinion (and any other opinion, from someone actively contributing to BW) would matter to those making decisions. Opinions can certainly be taken into account even if the person with the opinion is not participating in the decision. Claude Bombarde

Introducing "Trustees"

Good thoughts, Ted. We really are talking about a role which is independent of whether the person is an admin, editor, 'crat, etc. Trustees is a good word, I think, because it's short and it embodies that decision-making authority is exercised as a trust, on behalf of all contributors. So I amend my earlier proposal as follows: Decisions are made by a consensus of trustees after a suitable period of open discussion. The first trustees shall be ALittleSlow, Lar, Tedward, and Venkatesh. New trustees are selected by existing trustees using their normal decision-making process. --ALittleSlow

Works for me other than that 4 voters can split evenly :) ++Lar: t/
Suggest maybe we add Jeramy? He's done significant config work and contributed a year of hosting. Just an idea... ++Lar: t/
I would not worry about split votes. If the trustees cannot come to a consensus (majority support, no strong objections) then a motion/nomination should fail. And yes, Jeramy should be a trustee. FYI I support the proposal, accept my nomination and support the initial trustees list as discussed. Tedward
I support Jeramy's nomination, but we need to ask if he wants the responsibility first. --ALittleSlow
I put him on the initial list but if he does not want that role I totally understand and am happy to edit. Tedward

On to Mechanisms

Now that we have question 1 tackled (deciding how to decide), let's move to question 2: What are the (wiki) mechanisms by which we make decisions? It looks like Conventions and Open Questions are the two pages where this is currently happening, and Requests_for_adminship/nominations is documented as such a place. Are there others?

I propose that these locations, and others like them as we so designate, be the places where "a suitable period of open discussion" occurs and a decision is rendered. Trustees shall be responsible for watching these locations and expressing their opinions in a timely manner so consensus can be recognized readily . --ALittleSlow

Another page for trustees to watch: Trustees discussion --ALittleSlow
I wonder if creating a category of pages for trustees to monitor would make such monitoring easier, and would be easier for non-trustees to know what the Trustees are monitoring. Good idea? What name would make this function most obvious? "Trustee", "Trusteeship", "Trustee watchlist", "Yo, Trustees!" "Policy"? --ALittleSlow
I see no need for a new category for this as once a page has been added to your watchlist it is very easy to monitor. That said, a list of the pages Trustees should be monitoring on Brickwiki:Trustees itself seems like a fine idea and gives people an idea of what Trustees do. Tedward
Sounds good. Done. --ALittleSlow

Backing up a little bit to how trustees make decisions, so far the pattern is:

  • Pose a question on one of the above page mentioned pages.
  • Discuss.
  • Wait for a loud accord or wimpering silence.
  • Call it a consensus, or keep waiting.

It's that last bit that's got me troubled. The rule is "suitable period of open discussion" until a "consensus" is reached. I knew that was loose when I wrote it. My main concern is that we may wait longer than necessary to declare a decision, when we could be moving forward. A less likely, but more damaging risk is that someone may declare consensus prematurely, when in fact a trustee is simmering in silence (perhaps counting to 10 before posting). What do you think, do we need to define "suitable period" and "consensus", or is the current pattern adequate? [unsigned comment by User:ALittleSlow].

How about putting time limits on things? 2 weeks with no comment means "silence is consent" or what have you. For some things stating the period up front is good, for "major things" it should never be less than X and for "minor things" it should never be less than Y (if that makes sense, what is major/minor and what is X/Y ???) ++Lar: t/
I would say one week is good for most decisions but I can understand if people are offline for a couple of weeks. I suggest we use one week as the commenting period, accept silence=consent with the following exception: ZERO supporting comments (aka no seconder) as not consensus. We should always allow a motion to reconsider by a trustee if they really believe there is a problem. After all, circumstances change and we have reconsidered conventions before. Tedward
Works for me. Was that you or Brian or ?? that posted the first comment in this subthread? ++Lar: t/
It was me who failed to sign. Ted's suggestion works for me as well. I guess we'll wait the balance of 7 days for V before declaring consensus :) --ALittleSlow
Oh, gosh, and for Claude to comment, as well! --ALittleSlow

So this is now a done deal?? ++Lar: t/

I believe so. I'll write it up. --ALittleSlow
I documented it at governance. Please review and tweak. I also tried to capture the documentation questions (#3 and #4). If you find that acceptable, or when your improvements are incorporated, I think we can close this whole question. --ALittleSlow
Looks good to me. Tedward

New format for Table of Contents

I was wondering if we could use the formatting from template:TOCleft as the default? It looks so much better than the standard ToC (see Trains). That would be easier than having to remember to use the template for those articles that need a ToC. Tedward

It took me a while to see the difference. It's essentially just the float:left, correct? One side-effect I noticed was that if the TOCleft is near another box that's also set to float:left (Template:UserBox for example), they will display ungracefully stair-stepped. Even so, I'm willing to give it a try. --ALittleSlow

Can you summarize the difference? That text flows around to the right instead of leaving a big space? If so, works for me. I think the Big Wiki does it that way ++Lar: t/

Yeah, it is really just a float-left for the box which allows the text to be seen from the top of the page even when using a really long ToC. Very simple change I think but one that really improves legibility. Tedward
The big Wiki doesn't do it, at least in the default stylesheet. Here's informed advice. Also their version of Template:TOC left. I'll go ahead and implement it by modifing the CSS. If we don't like it, it's easy to change back. --ALittleSlow
I agree with the BigWiki article. TOCright seems useless and I think we can delete that one if like. Tedward
It's done. I looked at about 30 pages (in monobook), and only found two that may not have responded as expected: My_LEGO_Network, User:Lar. Someone should check the other skins, especially pages that use box and image templates (or anything else special) near the TOC. Rock_Raiders was surely much improved by the change. --ALittleSlow

Go vs. Search

There are a couple usability/friendliness issues I've notices, and which I think we should address before our public announcement. When you type something in the search textbox and press "Enter", the default button is "Go", which only finds exact matches. If you don't find a match and your are logged in, you get the option to do a full text search or create a page. This is a little disconcerting but one gets used to it. However, if you are an anonymous user, you get

Permission error
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in the group: Users.

At which my reaction (as normal user) is that this site is lame, and I'm gone.

The big Wiki combines the Go and Search functions. If your search turns up an exact match, you are taken there, otherwise it does a full-text search. What do you think about doing the same thing? I've no idea how hard it is. --ALittleSlow

Yeah, I find the GO button useless, especially as the default. A search box should "search" so I'd be happy to see the GO button just disappear. Tedward
I like how the Big Wiki does it. Also, I think that the search page should be usable by all folk. Yes, it is a DDOS vector to allow searching but not a huge one. ++Lar: t/
Turns out the Go button behavior is determined by a global variable ($wgGoToEdit or similar). Whether or not there is a Go button is governed (typically) by the skin. On the big Wiki some skins have it and some don't. Since changing a global variable is easier than modifying a skin, I plan to just change the behavior of the Go button to work like the big Wiki, as discussed at the top of this topic. Should take effect soon. --ALittleSlow
Sounds good! Tedward
Done. Oh, that is much better. --ALittleSlow
That is a big improvement! Thank you! Claude Bombarde

Merging with Brickipedia

Hi everyone, I'm back to flog the dead horse over hopefully getting BrickWiki and Brickipedia under the same domain again :-)

Well, I'm a bit more optimistic than that. However, I don't want any merger to happen if it would be unfavourable to BrickWiki, because I respect what has been built here and I'm not trying to destroy that. Quite to the contrary, almost all of the information contained here is on areas not well covered on Brickipedia, meaning that a merge would be beneficial content-wise. Brickipedia is more a set database, but there is certainly room for more general LEGO information, and such content is already within the scope there.

This proposal comes at a time when Brickipedia is moving off of Wikia, meaning two things. First, the BrickWikians wouldn't be dragged under the Wikia banner. I would never be so cruel as to come here and suggest that you join the Dark Side like that. We are moving onto our own hosting, supported by one ad which pays for the VPS and will hopefully generate enough revenue to host some semi-regular contests with real (but small) prizes. The move is almost complete: everything should be moved over and ready for editing next week if everything goes according to plan. Brickipedia will be run by an entity which we call the Brickimedia Association, which is governed by an elected board that hosts the contests, deals with enforcing copyright/COPPA law and reviews financial reports submitted by myself. We have a (rather disorganized) coordination wiki set up at meta.brickimedia.org, and Brickipedia will be at en.brickimedia.org. There will be a couple of other LEGO wikis also hosted there, but non-content - there will be the LEGO Message Boards Wiki, a LEGO fanfic wiki and a LEGO customs wiki. They aren't really trying to beat out competition like MOC pages, but more as a place for Brickipedia contributors to share their own stories and creations.

Second, the content and contributors from BrickWiki would really help to establish the new Brickipedia, and of course you would all have a say in the direction that the project goes. All changes are done either by a discussion/vote open to the entire community, or (in rare and mostly legal cases) by the Brickimedia Board, which is an elected body.

Anyway, back to BrickWiki and merging into Brickipedia. Like I said, the content is compatible. The largest issue that I see is the userbase. Brickipedia has around 100 active editors who regularly contribute to the content (that number will go down after the move), but most of them are younger. Most of the people who contribute to BrickWiki are AFOLs. You probably won't appreciate the style of discussion which happens on Brickipedia, quite a few of which are more drama-based than actually focussing on the wiki. The same thing happens on any big wiki, but I suppose it might be even worse on Brickipedia. This is (IMO) an area of huge benefit to Brickipedia - I would love to have some older people around, if nothing else to provide the occasional infusion of sanity. I also hope that the post-move Brickipedia will attract more AFOLs with less of a Wikia-feel.

What we can offer you: Wider reach, more contributors, an incredibly fast site with constant uptime and ultimately a better medium to expand the content that BrickWiki offers. And, unlike Wikia, if BrickWiki contributors don't like it on Brickipedia, we will delete the specifically-BrickWiki content after you've moved away from us. This isn't an attempt to absorb you.

Obviously, this won't cover all of the details. But, I think that this is a good start for discussion. Feel free to ask any questions, since I can probably clarify the points that I've missed here. Thanks for your time, Ajraddatz

The good:
  • Brickpedia is leaving Wikia. I might be able to stand to use it now.
  • Brickimedia is apparently going to use Mediawiki. Not the best for new editors, but good for this editor.
  • It would be nice for the fan community to have only one wiki.
  • It would be more efficient for supporters to have only one wiki to support.
  • More editors
My story: I had done some Mindstorms software research and gotten some results which I knew were not anywhere on the web. I looked for a place to share them. I created an account on Brickipedia, and somewhat ineptly but in good faith posted my findings. While I was still adding content, an admin, in violation of Brickipedia's own deletion policy, was summarily deleting my posts. Within a couple months, I had helped restart BrickWiki. In short, I have a bad taste that will somehow have to be washed out before the good reasons to merge are good enough for me.
The potentially bad:
  • Deletionism. I am inclusionist, more so even than what is in the scope of BrickWiki. It would be a struggle for me to move to a more deletionist site.
  • Loss of control. I'm not much of a control freak, but it's still a tough thing to give up.
  • Advertisements. I just don't see how the benefit outweighs the cost.
  • More editors
ALITTLESlow: t/
I certainly understand your concerns. Quite a few of our users, especially admins, have the unfortunate tendency towards mistreating new users, and seem to love deleting content. I do assure you that the entire wiki isn't deletionist - I myself am rather strongly an inclusionist (even more so on Brickipedia than Wikipedia), but I'm not alone. Honestly, the addition of the BrickWiki community would probably help this, since there will be a stronger voice for expanding, rather than limiting the scope of what Brickipedia can cover.
For control, your adminship (or bureaucratship in some people's cases) will transfer to Brickipedia. That's a standard I have for a merger, otherwise I'd call it a takeover :-)
If you needed it, I can also provide you with access to the more technical aspect of the site. If you can work with SSH/FTP without breaking the universe, then backend access isn't a problem, assuming you don't go making changes without some sort of prior community approval.
The big thing with the ads (ad, singular) is to get back my $70 a year that I pay for the site, but more to host contests with real prizes. I would personally love to be able to provide some sort of physical reward to good editors, and get some new people involved. Contests are a fantastic way of doing this, and on-wiki awards can only go so far. If the single ad is generating more than enough money for both, then it will be taken down for the remainder of the year. Money isn't a big concern for me, since I make well over $70 a day anyway, but it would be nice if it were self-sufficient (especially if someone else took it over in the future).
If any merger were to happen, I would first make very sure that the Brickipedians were willing to expand the scope of the content allowed, which is really a common-sense thing to do. I am also trying to impress on the users (and especially the admins) that they need to be far less BITE-y if the new site is going to work. Ajraddatz
I don't know if it would be helpful, but you (or anyone else) can contact me via Freenode IRC if you want to chat in real-time. When I'm on, I'll usually be in #wikimedia-stewards or #wikimedia-wikidata if you wanted to find me and send over a PM. Obviously lots of these details will need to be worked out after the move with the entire Brickipedian community, not just me. But, as the person who is kind of spearheading the move, I can probably provide some answers to questions or concerns that you have. Logs of any conversation could also be posted so everyone here knows what was said. If I'm not on, leave a message on my talk page here and I'll get on as soon as I can (unless I'm busy with something else, but I should be free today in three hours or so after leaving this message) Ajraddatz
What's your role(s) on Wikimedia projects? (ex steward here)... This is a proposal I could support more easily than previous ones. The deletionist bent and drama give me pause though. Those are among the reasons I never edit any Wikimedia projects any longer. We are a fairly sober, calm, and drama free bunch. I don't relish the idea of having to seek "consensus" ,where that's achieved by convincing whoever turns up, to prevent radical deletions. What is the process for admin removal? Is the admin who summarily deleted Brian's stuff considered a good admin? I'm skeptical but convincable. ++Lar: t/
I'm a global sysop on Wikimedia, and semi-active on the new project Wikidata (trying to get common sense based policies going rather than imports from enwiki). Honestly, I don't think that Brickipedia is as deletionist as you think - for the most part, I've found the community willing to accept new types of articles. I would like to think that the unfortunate experience above was a mistake, but I've started a private discussion among the other admins to make sure that they are OK with both expanding the scope of Brickipedia to include BrickWiki content, and to being a little bit more liberal with keeping pages that have some benefit for the project. Admins require 80% support to be elected, and if a thread for removal of adminship comes up, admins need to be able to keep that 80% support or else they lose the bit. There's no requirements for starting a forum, though obviously there should be some discussion of misuse rather than immediate desysopping. Our system of making decisions is the only thing that I can't really make comment on - that's how we've always done it, and we value giving all of the users on the site a say in where that site goes. On the new hosting, there will be a five-person elected "board" that does a few global things like hosting contests, dealing with the checkuser and oversight bits and removing copyrighted stuff to hopefully avoid excessive drama in those areas.
To just summarize into answers to your questions: Adminship can be removed by a community vote on the forum (usually advertised to get a wide range of opinions), and no, that kind of deletion against policy and biting the newcomers isn't something that is widely supported.
WRT that, could ALittleSlow please provide some specifics that I can work with (links if possible). Then I could have a better idea of what actually happened, and could answer for certain whether or not it was sanctioned behaviour. Ajraddatz
This is such a hard question for me. I really wanted a merger and "one-stop-shopping" as it were for an online LEGO reference for a long time. At this point however I just do not see how the two can merge. We have worked hard to categorize articles on BW to present a rational and useful reference tool. When I look at Brickipedia I get a headache and can find little or no effective categorization of articles. Navigation seems random and the Brickipedia community seems to like it that way. Are you suggesting that they might be willing to make such a profound change to their structure? Tedward
It's kind of funny - I'm taking flack from both sides of this over pretty much the same issues. Many Brickipedia users find BrickWiki to be a mess in terms of categorization (and the number of stubs), and I guess you see us in the same way. This merging certainly would require some work by both sides.
On Brickipedia, we are trying to improve the organization. That definitely isn't something that the community is happy with. Our categorization is fine, but everything is sprawled all over the place... Honestly, I'm not even sure how to improve it, other than more portal pages. Ajraddatz
Where on Brickipedia is this being discussed? I'd like to see the discussion there as well, before I finalize my views on this. Brian, will I see you this weekende at BW Indy? Maybe we can talk about it there... ++Lar: t/
I haven't done up a proposal on Brickipedia yet - we're focussing on the move right now. I've just asked around to some of the users who I know would have a problem with this. We should be done the move in anywhere from a few days to a week. Ajraddatz
Let's see, links:
  • This diff has the only relevant edit I can find. The rest are deleted.
  • NightblaseSaber's talk, where I aired my grievance. and
  • my Brickipedia talk page, where the offending and another admin(?) responded. No place here for fan-created tools? Drama! Puke. Run away.
I regret to report that reliving this did not help the merger cause. On categorization, I browse very little and search very much, so I can't see me ever having a strong opinion on that. Lar, I will see you at [[Brickworld|BW Indy].

It's been a while since I've been there. I forgot how the place looks... "60 achievement points" for 4 (undeleted) contributions? I like how things look here. Spare, serious, clean and not overdecorated. The only thing we should change is we should adopt the red 2x2 brick as our "globe" instead of the current one. :) ++Lar: t/

Yeah - the new wiki is going to be slightly different. We have the basics set up here - the images will be imported tonight and the content over the next couple of days, hopefully. We had a bit of a setback when I gave someone root access and they deleted the user table, so we had to reset the databases (something which won't happen ever again). With the incident above, that removal was correct, as such content isn't currently within Brickipedia's scope. However, we have been wanted to expand that scope for a while, to avoid just being a duplicate of Brickset, and any merger with BrickWiki would come after such an expansion in our scope. Ajraddatz
OK, I had another look at the current site and the "new" main page you linked to above. As it stands now Brickipedia has four stated goals/functions/areas:
Encyclopedia: Comprehensive database of LEGO products & themes

Reviews: Write and read reviews on your favourite LEGO sets

Customs: Create and share your own LEGO creations & themes

Forums: Meet fans and discuss LEGO sets and themes

As it stands now it appears that our missions overlap not at all. Brickipedia is a set database, a review collection, a MOC sharing site and a forum. Why would you bother also trying to be a hobby guide? The goal of unity and comprehensiveness for an encyclopedia is admirable but has already been achieved. Right here. Are you going to ditch the non-encyclopedic side projects that are already covered by Brickset, MOCPages, Eurobricks etc or are you going to try and merge them as well? I see no need for a merger and advantages to not merging. Why not make Brickipedia better at what it is clearly good at rather than try to take over the whole LEGO intertubes in a single all-encompasing site? There is no reason people cannot work on both sites. If people want to do articles on the the hobby they can come here. If they want to contribute to a set database/sharing site they can go to Brickipedia. Perhaps what we need is easy linking between the two. Sorry I don't know the technical term but like we make links to Wikipedia: [[wikipedia:LEGO]]. Maybe we could both make a verson s that we could link to you (ie. [[Brickipedia:set_name]]) and vice versa (ie.[[Brickwiki:element]])? Tedward
I like that idea better than a merger. At least for now.
...said Lar (who has clearly been exhausted by booming sales at Brickworld Indy. :)
  1. It turns out to be significantly harder to discover how to set up interwiki links than it does to actually set them up.
  2. I find no fault and a lot to agree with in Tedward's analysis.
  3. I still dream of a single wiki for LEGO hobbyists, but for now both my mood and opinion are to wait and see how Brickipedia evolves. ALITTLESlow: t/
Some sort of partnership would still be beneficial for both sites. Once Brickipedia is set up, I'll see what I can propose there about that. Ajraddatz
That sounds like a great plan. Good luck with getting your community to change... let us know how it goes. ++Lar: t/

I said I would wait and see, and I've done some of both. Heretofore I have conceptualized a Brickipedia merger. The LEGO Cuusoo Wiki, on the other hand, has moved from Wikia to Brickimedia, but not merged with Brickipedia. A visual comparison between the two sites is instructive. LEGO CUUSOO Wiki has entirely maintained their original look and feel, sans Wikia baggage. A similar move by BrickWiki has the potential to realize most of the benefits Ajraddatz promulgated with much reduced risk of realizing our fears. I think there is a bit more waiting and seeing to do still, however. ALITTLESlow: t/

We could definitely host Brickwiki, with the same domain name at that. We still have lots of work to do on the site, though. Ajraddatz

Hosting fees

Hello BrickWikians!

Our hosting fees were paid/donated up to April 28. SiteOrchard will be sending an invoice any time now, I expect. Soliciting contributions for this year. ALITTLESlow: t/

$25 received. I'll put in another $25. Only $49 to go and we're another year in the black! ALITTLESlow: t/
so we're now 18 months past this discussion and still have not arrived at a consensus of what to do. Do we merge with Brickipedia? The hosting fees don't pay themselves. I confess to have had little interest in this project for a while now, sorry. ++Lar: t/