Wedge

No-one seems to understand why I complain as much as I do about the fallacy of maintaining a hit count.

Well, here's a perfect example. We have 9 users online. 2 are real, 6 are already logged as bots, the last one is... shock horror... a bot too.

Yup, that means that 77% of the users online when I just looked at not actual users. I don't think I've seen it go below 50% in the last few weeks (whenever I've been able to look)

Since we can't always keep an eye out for bots, and can't always keep the list up to date, seriously can't we just stop counting the number of online people yet? Or at the very least stop counting the records? (I still don't even want them shown to admins, to be honest, I'd rather just not track them)

Scrolling up and down this page I can see issues too... e.g. the userboxes from reply 26 and 27 sometimes overlap when scrolling.

It's always one of those things, we can make it crazy powerful but there are going to be issues with people wanting to customise it. Perhaps it would be better to keep it simple?

That is something I've been meaning to do though ;)

Eh, I still think the contributors file is the way to go here... it's still a WIP but...


It's not practical nor entirely reasonable for us as a separate project to list everyone who worked on SMF - but we do note that it had other contributors who weren't/aren't necessarily team (i.e. SMF "and its contributors")

This is petty but I'm frustrated, having just been part of an argument about the SMF credits.

They're already messed up and in 2.1 they're actually likely to get worse. Right now, for example, the plan is to have the current team up first, followed by everyone else as 'Friends', followed by Github contributors and stuff like that.

Now, I think it's nice they're actually getting Github contributors. I also understand there are a number of people who don't want even the Github contributors credited. There's nothing better than that for 'we'll take your commits but fuck you for wanting some credit to them'.

But the bit that's getting me frustrated is the absolute inability of some people to understand why lumping all the Friends together is actually fucked up.

Let me put this straight, and I'll try to use small words so everyone understands me.

1. SMF is a software project. Without the developers developing it, there would be no SMF.
2. If there is no SMF, there is no need for support, customizers, translators etc.
3. The only conclusion I can then draw from this is that developers are actually necessary to the project in a way that other roles aren't.
4. Support, Customizers, Translators are all important. But they, by necessity, must come second to developers because without developers, there's nothing to support, nothing to customize, nothing to translate.

Assuming we agree on the above:
a) Developers' contributions do not stop being important just because they left the team. There are still bits of the original SMF 1.0 (and, while we're at it, elements from YaBB) still in 2.0 and even in 2.1.
b) The current developers, as fine a people as they are, did not write 95% of SMF's code, because of the above.
c) Why, then, are the current developers considered as rock stars compared to the 'Friends' who are no more important than anyone else despite the fact that some of the Friends actually wrote the damn software?

It seems very simple to me: anyone who actually contributed code to SMF, i.e. those who MADE SMF need a higher billing than the people who support it etc.

In case anyone thinks this is about my getting my name higher up... no. I never made the dev team for various reasons. My code contributions are small enough that I don't personally consider them important enough to be considered a developer. I have no qualms with, then, remaining in the Friends list, provided that the people who actually made SMF get a slightly higher billing - after all, they're the ones who made it, and if SMF hadn't been made, I wouldn't have had anything to contribute.

And yet this mindset is still rife in SMF, that developers are not any more important than anyone else. Yes, that's right... in a project based around a piece of software, the people who make the software are not particularly important.

Imagine if that applied to other industries. Imagine if we told book authors, that suddenly they have to credit the publisher as being as important in the book's making as themselves. Now, books have the author in big letters on the front, and the publisher's logo on there too but when was the last time you saw the publisher receiving equal prominence to the author? What about the typesetters? The proof readers? The author's best friend who proof-read an early script? The author's partner who gave them moral support? By SMF's definition, we should be giving all these people equal credit to the author, regardless of anything else.

Apparently I appear to be in the minority of people who understand this. It's sad really, especially in light of other recent events where for one brief shining moment I was considering helping with SMF core development.

Not exactly an Easter Egg... that's Earl's Court. When the DW Experience was at Olympia (which is next to Earl's Court), they had that there for promotional purposes. As for the business listing, I'm not sure that's an easter egg either but actually set up intentionally. Could be wrong though ;)

So I've been thinking about searching and the way searching works and I've concluded a number of things.

1. I want Sphinx and ElasticSearch in the core
Both Sphinx and ElasticSearch are pretty mature. Both have live update features now, so there's no reason we can't support them both with a sort of push mechanism (rather than Sphinx's pull mentality, like the old API was geared for)... the API needs rewriting to support either anyway and I might as well do it all together.

2. I want to natively support other types of data than posts.
The current setup doesn't support anything other than posts and I want to natively offer support for other stuff - calendar, helpdesk etc. The backend can support these extra things with some work, and pushing these also allows nice support in both ES and Sphinx.

3. It adds some nice feature parity with other systems without adding a ton of headaches for support.
XenForo offers ES with a $60 plugin, though I'm not entirely sure why. IPB has Sphinx in the core. Neither appears to have a huge support overhead because of them. And for the most part once they're done, they're done from our point of view.

4. The most controversial aspect of this is what I want to propose last: ditching unindexed searching.
Right now, the default searching method in Wedge is as it is in SMF: no index. It's slow, and doesn't scale beyond a few tens of thousands at peak. In fact, where we are right now on wedge.org is probably about the limit of what we can do with an unindexed DB before performance starts to go nuts. (40k is really the upper limit)

Now, partly this is because we've never configured it to be anything else, and most people just wouldn't know to do so because they wouldn't know any better. Now that's fine, because we know that people don't generally touch the settings unless they're directed - but using the search index would deliver better search performance from about 1k posts and up (and largely a push in performance terms for where things are right now for fresh installs)

I see no reason why 'no index' ever needs to be a valid search type. I'd suggest dropping that entirely and using the 'no index' option to mean 'no searching'. And then leaving the other index types to be actual index types, which would simplify the search code as well (and properly allow for it all to be segregated back to the APIs, some of which has already occurred but plenty more still to do)

This would leave us with three working search types (standard - formally known as custom, ES, Sphinx), of which 'custom' would be set as default on installation and would be populating posts as they are created (rather than having to deal with a huge index creation at once)

ES and Sphinx are both VPS level options, but there's no reason we can't have people pushing content to these indexes while using the custom index - plus of course there are always options for rebuilding indexes.


Does any of this make sense? Any questions?