WelcomeWEFreedomWindsorEssexCounty-ActionCommunicationsRalliesResourcesSocialEventsWednesdayNightMeetings-ActivismAgoraAgorismCanadaCommonLawCommunityDataCentersDataCentresDoocracyFarmersMarketIntroductionsNaturalLawNewslettersOntarioOrganizingOutreachProjexProjexWikiRalliesResistanceAnalysisSoireesSoiréesWikiSpooksWindsorElectionsTop Subs
8
MatrixDev - - (+7|-0)
Should I add back fast cross-posting?(self)
7 commentsbyx0x7

There was a feature, before I modified the forms, for submitting links to more than one topic at a time. The hope was to help accelerate filling in what folks typically think of as default subs: Videos, Funny, ect; especially when the site was new.

It was supported on link posts rather than text posts because it made sense to have a discussion post in one thread.

When the link form and text form were unified this unified form didn't adopt support for posting to multiple topics with one submission. And when they were "split" apart again (just hiding unneeded fields), the multiple topic per submission logic is still missing.

Easy to fix, but the question is, do we want the feature? I've already heard mixed views in the crowd so let's make it a poll.

Comment preview

[-]JasonCarswell3(+2|0)

[x] What about metatags?
[x] What about multisubs?

Subs (aka communities) aren't that important if you have parties (aka groups).

The metatag descriptors are the briefest overview to explain what category, field, topic, or social group the post relates to.

Among other venues Steemit had a limit of 5 metatags which was usually more than enough, but sometimes you'd have more descriptors forced to be creative and/or strategic on how to get max views.

It always made sense to have discussions in just one thread, where communities (subs or parties) could intermingle.

IMO, lose it all but keep the one (dual) submit form - and add metatags for the OP, plus user addon metatags. (Additional metatags shouldn't count as posts.)

I hope that all the effort we take to participate (including titles, tags, etc.) is not lost in the ephemeral memory hole of relentless time, rather, that one day we can have the tools to be able to research through the vast archives of our posts and comments with minor effort to dig up relevant material for future use in practical projects. Or maybe this is just a forum for idle banter to most users. Either way, I prefer reasonably organized discourse in our well-kept hangout rather than an embarrassingly messy living room where guests ask how can we live this way.

parentlinkreply
[-]JasonCarswell2(+1|0)

Bring it back but limit extra topics to major subs

Please explain.

parentlinkreply
[-]x0x72(+1|0)

Basically the form accelerating cross posting was never intended as a placeholder for metatags. It was intended to fill in major subs faster so the site could get to the point where someone can type in /s/Funny or /s/Videos or any other major topic and reasonably expect something to be there. We are there now. But in every beginning that isn't going to be the case, so it was a concern for a while to get there as quick as possible.

In the hypothetical that I added this limit to the form accelerating it, it doesn't mean obscure subs couldn't be cross posted to en masse. It would just take a little more manual effort.

But if there were a limit like this that made extra subs limited to major topics, basically it would check that at most one sub in the list is "obscure." There would have to be a heuristic for what is "obscure" vs not. Either a set list would be considered major topics (I'm not a huge fan of that), or the metric would be that a sub has multiple recent posters in it. That's a reasonable heuristic for obscurity. We can expect many people have posted recently to /s/Funny. But we can't expect that many people have posted to /s/OccultistCostcoWorkersInNorthMichigan. But if multiple have I guess it's not obscure.

The other benefit to not letting that form take a list is it reduces potential bugs and complexity in code. As more features get added something can always go wrong when every function, and data at rest, that involves a topic has to be compatible with the argument being either a string or a list. For a while your post whenevers, and only yours, were posting but not going from the queue pile to the done pile. They would repost again leading to >100 cross posts. I never tacked down why and instead made a scheduled observer for when that happens that just deletes it from the queue pile. That and I'm assuming that was what made it so you and only you inexplicably weren't getting bonus points on some posts despite the fact that I've grepped the server over and over and there is no code with your username in it singling you out near any related system (or any system). So that's more bugs to track down and bandaid code. Both get in the way of developing new feature cleanly.

Or... you could just hit submit multiple times.

Plus there is also the fact that it does annoy some users. So maybe I shouldn't be adding in accelerators for that. So if it takes a little more grind, I'm thinking it's not the end of the world.

parentlinkreply
[-]Neol1(0|0)

I'm with Jason on this - on reddit it makes sense to crosspost because different subs have different people and different rules/mods, and here it's basically one community and one set of mods (except potentially via parties), so it doesn't make sense to split the discussion among multiple posts in different topics.

It's better to think about how to implement multiple tags/topics for one post, and alternative discussions would exist via party functionality.

parentlinkreply
[-]x0x72(+1|0)

Wouldn't that argue more for not engaging in massive cross posting? It's all going to the same general community. The topic ends up being a bonus label which is less necessary here but still nice. But if a single topic for something here is already overkill in this site's context why multiple?

A many to many relationship in the database being used to drive subs just becomes harder to process fast. It would push forward the timeline to do the practice of archiving posts to balance the performance hit. Which is a concept I've never liked and would prefer to hit that point never.

I think what I may do is add an interface to add tags, knowing a few folks want to put them in. But I don't really have an outlet to use the data, which makes it functionally a pacifier.

But it is true that maybe I'll be able to do something cool with the data in the future, so I should invite that data to come in even if it won't immediately drive an actual feature.

parentlinkreply
[-]Neol1(0|0)

Wouldn't that argue more for not engaging in massive cross posting?

Yeah, that's why I'm not crossposting, but I would use tags.

A many to many relationship in the database being used to drive subs just becomes harder to process fast. It would push forward the timeline to do the practice of archiving posts to balance the performance hit. Which is a concept I've never liked and would prefer to hit that point never.

Maybe I misunderstand something, but why "many to many"? Why not something like this:

posts db: post_id, other fields

tags db: tag_id, other fields

posttags db: id, post_id, tag_id, [other fields] [multiple records per post]

Isn't this one-to-many?

But I don't really have an outlet to use the data, which makes it functionally a pacifier.

"Select posts by tag" is an obvious feature to have then.

parentlinkreply
[-]x0x72(+1|0)

I guess whether it's one to many or many to many depends on perspective. Every post can have many tags and every tag can have many posts. That is many to many.

But it means that you can't drive the ranking algorithm out of a single table. Because either a one to many or many to many relationship needs a separate table just for that relationship.

Even outside of viewing a specific sub, the topic field is relevant because of user filters and party filters. Plus if I add subscribing to topics, then again.

I could make every single tag a partial index. But then it would be better to have a finite number of tags.

parentlinkreply