* - if user has JavaScript enabled, non-JS users will get the current behavior.
From a user perspective, the most visible changes are just more streamlined site performance. Inline reply/moderation is something that was by far the most common request the last time we asked for feedback on the subject, and I am hoping to have it implemented with this release. (Fancy URLs, the other largely requested feature will require consider effort to find and fix URLs throughout the codebase; I do not have an ETA on this feature, aside from the fact its on our roadmap).
Migrating from standard MySQL to cluster should help us considerably keep the site up for longer periods of times; we have previously experimented with other MySQL replication solutions, and found them all lacking, especially in cases of master failover. With this update to Rehash, we can take a database server offline and not have the site come crashing down, or require exceedingly large amounts of effort to replicate and reconfigure the front-end servers.
While this covers here and now, I've long liked to have plans 6 months to a year out, and post them for community feedback so everyone is in the loop on both what we're doing, and why we're doing it.
* - our initial focus is going to be on left-to-right languages. While RTL language support is something I'd like to support, this is likely going to require a massive amount of effort beyond just getting the site translated, so unless a large group of folks step forward to help build say an Arabic or Hebrew version of SN, RTL support is not super high on the priorities list.
Non-English speakers are likely familiar with the two major spin-offs of the other site, specifically Barra Punto and slashdot.jp
Both of these sites are running on rather dated versions of slash, and lack much of the port and polish that has gone into the back end since they were launched. We feel that we can do better, and want to give the non-English users of our site a chance to help build better news portals. We've already have significant interest in making the site available in Spanish, and I met a bunch of Polish SN users when I was in Warsaw last summer; I want to provide the community with tools to take what we've done and take it further.
Between now, and when we are technically able to, we hope to find volunteers who would be willing to edit and manage a non-English version of SoylentNews, and thus allow them to "hit the ground running" so to speak, once the site upgrade launches.
On user-created nexuses, as I've indicated before, this essentially will be our version of subreddits, allowing any topic to be discussed on SN. Prior to implementation, we, as a community, need to define a formal code of conduct, as well as determining what, if any, monetization should be done; while we can cover our hosting costs from the revenue brought in from subscriptions, I'd like to eventually get to the point that we can hire both full-time developers and editors. While this may still be years out if ever, being both fully self-sufficient, and being able to cover development and sysadmin costs (vs. being 100% dependent on volunteers) is an important step (though this is a discussion for a future article).
Moving on, let's take a look at where I'd like to see us by August ...
Rehash 15.08
Right now, the staff directly handle both content, and handling of users issues. For the most part, I'd like to think this works relatively well, but once we have users who can manage their own parts of SN, we need to make sure we have mechanisms in place to handle user grievances. While I'm unsure how much of our community uses Reddit, many are at least passingly familiar with the some of the drama that has come out of various subreddits, and the lack of transparency from the admins.
By having defined mechanisms of governance, this will allow the admins here to intervene should it be necessary, and allowing disputes between nexus admins and their users to be resolved with a minimum of drama and such, as well as making sure we don't compromise the values on which this site was originally founded.
On a technical level, we also are looking at moving to postgreSQL in the long term. While it may seem odd that we're doing two rounds of major database work, migration to MySQL cluster merely helps handle availability issues, aside from removing FULLTEXT searches, it has not been necessary to rewrite much code to allow the site to operate on a cluster. Migration to MySQL cluster is more an increment improvement then a massive rewrite of the guts of the site
For those unfamiliar with MySQL, it lacks many of the features that are present in more robust databases. Its not uncommon to have massive JOINs spanning 3-4 tables in the current code base, or large amounts of database logic written in Perl due to limitations in MySQL views, triggers, and stored procedures. By migrating to a more advanced database, we hope to drastically reduce (perhaps by half) the amount of code present in the front end and reducing our long-term maintenance burden. Obviously, until we start the effort to port the back end the true difficulty of this will remain unknown and it may well be, once we dig deeper into it, that the cost of migration would outweigh any benefits.
In Closing
Since we went live a year ago, SoylentNews has been, and continues to be an adventure. I'm committed to helping us reach the goals set out in the manifesto, constantly placing the community first, and allowing this site to grow and thrive. Your feedback is extremely important to know if we're going the right way, hence why I'm laying down where I want to go now, and then seeing if everyone feels like its a good move. If not, I'll go back to the drawing board, and try again. We wouldn't be here without you guys, and we're not going to forsake the folks that got us this far.
Until next time,
NCommander
(Score: 5, Interesting) by martyb on Thursday March 19 2015, @02:48AM
I have encountered situations where private message would be useful on SoylentNews.
Please note that there are no cases listed above where one *user* on SN private messages another *user*.
Maybe create 'roles' or 'lists'?
That all said, this opens up a whole can of worms for potential abuse (e.g. spam or flooding) , and we may find ourselves effectively recreating email or IRC, but badly. So, I like the general concept, but am somewhat apprehensive depending to the details of the implementation. I would like to see a full specification of use cases and error handling before committing either way.
While I have the thought, It would be useful to have a role default to accept all PMs from all users, but that would be open to a PM flood.
Possible Countermeasure: What if, *any* user could PM 'Editor' (or 'Dev', or whatever). Maybe they want to send another PM? Fine, but they have to wait 1 minute from the time the last PM was submitted. Want to send another PM? Now they'd have to wait 4 more minutes from the time the last PM was submitted. The next would require an additional 16 minutes, then 64 minutes, etc. As soon as that user receives a reply from that role, though, the timer/counter resets and that user can again reply immediately, with the progressive delays until such time as they receive another reply.
Wit is intellect, dancing.
(Score: 2) by mrcoolbp on Thursday March 19 2015, @02:26PM
Or implement a CAPTCHA on for sending PMs, or revoke outgoing PM privledges for spammers. Tie-in your idea for ACs.
(Score:1^½, Radical)
(Score: 3, Interesting) by Yog-Yogguth on Sunday April 05 2015, @01:48PM
I hate captchas so please let's not use anything like that.
Much better if people can disable PM's from anyone but those working on the site (i.e. those who could make an entry in your journal if they really wanted to), maybe that could even be the default (there could be lots of settings like allow Friends/Foes etc. or maybe a separate Friend/Foe etc. list for PM's).
And/or a PM system could be as simple as a continuously open/running and sticky journal entry (that isn't actually in the journal) and which one could decide whether or not to share with everybody. It would only need to hold a month of messages or something like that before the oldest gets deleted or it could be deleted (or maybe even that is unnecessary) by the owner on a per-message basis. I guess what I'm suggestion is a hybrid of a journal entry and reply notification.
(Sorry if someone has already suggested this stuff, haven't read everything).
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))