[ home ] [ site / arch ] [ pony / oat / anon ] [ rp / art ]

/fic/ - Fanfiction

The board for fanfiction review, brainstorming, critique, creation and discussion.
Name
Email
Subject
Comment
File
Flags
Password (For file deletion.)

Site maintenance in progress! Posts made now may be lost.

Ponychan-MLPchan Merger >>>/site/15219

File: 1352897852688.gif (140.22 KB, 500x300, Amonloving.gif)

Anonymous 1005

#Discussion

I think now it a good time as any:

As you might have become aware, Demetrius and I have recently gotten interested in ways improving the current set-up of the review assignment and distribution, trying to make people not have to keep tabs on the system and simply review/write. Basically, he wants to make it as automatic as possible, which I agree is a good goal.

At this, however, we have two proposal (and I don't think having more would hurt anyone) as to how to best achieve this and having some input from others might be helpful.

So, this thread is being made to have a place that isn't the Training ground filled with said discussion.

Opine and drop off why something might not be possible, or make your own proposal.

That's about it.

dolfeus!doseuxbE3s 1006

File: 1352900847110.jpg (41.71 KB, 462x462, 9842239_gal.jpg)

>>1005
You might want to add the #Discussion tag to this, but, anyway, good luck. I'll drop by some comments on this later today.
This post was edited by its author on .

Anonymous 1010

Demetrius, copy-paste your own, there is a ton of programmers here and I'm sure they'll find which one does the job better (as in, more efficiently).

And, here is my proposal:

Ok, that might have been a bit long and confused (I was just coming up with the idea and didn't think things through), so let me summarize it: if you make a series of spreadsheet that communicate with each other, and make the sole interface needed to interact with them be the forms, you have a system that needs no learning curve beyond reading the form's required information, maintains the tracking outside the control of any one website and effectively makes it be for all websites that want to track reviews, and allows for later expansions of its capabilities (for example, you can make the spreadsheet send an email notification to the person when his review is done, which isn't system critical but it is a nice addition that I have trouble seeing being implemented in here).

A person might be needed to keep track of errors people might make in using the forms (that would still apply with things here and there would be no way to make it automatically check for even obvious ones), but if the triggers and events can be set up correctly watching the spreadsheet would be a matter of watching for bugs and fixing them.

So, let me put the goals as I understand them:

1.) The system has to keep track of reviews requests.

2.) The system has to keep track of review claims.

3.) The system has to keep track of actual reviews.

4.) The system has to be simple enough for anyone who wants help to be able to use it.

5.) The system has to be as automatic as possible to prevent maintainers having to pore over threads and websites.
If you think the system should do more than just this, please let me know and we can add it to the lists (may I suggest making a thread for this?) just so we know what everyone is talking about.

So, now, let me define the system:
• There will be three spreadsheets with however many sheets and diagrams one ends up needing.

o The spreadsheet, for our purposes here, are called RW, RR and RB (review writers, review reviewers, review back-end).

o Each spreadsheet will have a form which will request their pertinent information: RW would ask for information of the story and writer that needs review, RR would ask you to say which story you would like to claim and what handle you are going to use, and RB will receive the information of where did you post the review (grossly simplified).

• The spreadsheet will have scripts, functions, and conditional formattings which will make them change dynamically as new information is introduce into them, all while trying to keep the information as simple as it can.

o The scripts will be in charge of keeping the different spreadsheets aware of the different information they will need to work: if one introduces information into RW for a review, the script in RW would then send part of the information to RR so that when one interacts with RR it knows what you are talking about. Here is another breakdown of the steps and the work of the scripts:

 Author A, with his story #1 goes into RW and introduces all the current needed information into the form attached to that spreadsheet.

 RW’s script grabs the information of the form and then introduces the relevant parts into the main visible sheet, gets the rest onto another sheet so that it is temporarily stored and then sends the review relevant parts of this information into RR. At the same time, it sends the whole information to RB and it gets recorded there.

• Currently, spreadsheet RW has a record of the request by author A, with two boxes for recording if the review was claimed and where is the review open and waiting for the rest.

• On the other side, RR has received from RW the relevant information it needs for a reviewer to make a claim from the form in RW and is ready to be read by whomever wants to review (which normally means you are already familiar with the far simple spreadsheet RW, with its reduce data). Basically, the current spreadsheet but with two important differences: each story will receive an ID so the system can easily recognize it and there is none of the necessary maintainer data fields.

• As for RB, as it names implies, it simply exists to be in the background making sure the system is fully automatic and records all the information, which could then be used for whatever you might have wanted, but as far as the normal user is concern (and the owner, for that matter) this spreadsheet doesn’t exists and simply provides the back information for the next few steps. For now, it just receives the information and replicates de ID for a couple of sheets.

 Reviewer A goes into RR and notices a story he likes. He goes, enters the necessary information in the form, and this makes him have a claim for it. A handle name, the ID of the story, and he is on his way to review it. In fact, notice you don’t even need to check the RR to confirm the ID, just go to RW and introduce the ID in the form of RR and you are good.

 RR, noticing this, informs RW that it has been claimed and modifies the relevant cell with the handle of the person whom has done the claim.

• RW now has changed a single cell thanks to the scripts, which now tells the writer that he is being reviewed by Reviewer A and no one other than each other has been involved.

• RR now checks the changes and removes the row from the sheet, clearing the space and effectively doing the work of the unclaimed sheet, but not before sending it to RB and making it keep record in yet another sheet.

• RB, in the meantime, simply modifies one of the secondary sheets, records the review claim, and just waits like it has done before.

 This is where it gets tricky and interesting: At this point, you have three spreadsheet with similar information, RW and RR having for the most part only the necessary information, while RB has all the information and uses different sheets with the same story ID recording all actions up to now (the creation of the request and subsequent information with its ID, and the claim by the reviewer). At this point, the reviewer finishes his review and decides he is ready to give it to Writer A.

• Reviewer A goes and enters the form which is going to be attached to RB (but remember, he doesn’t need to actually see RB, RB is again the back-end to make the interesting things happen) and provides where he made his review (which could be anywhere, he doesn’t even need to provide a link if he happens to send by email or just make it in the requesters Google docs), with the ID of course.

• This causes RB script to communicate with RW, which until now has merely being providing information. The script proceeds to give RW the link provided and RW changes the relevant cell with this information, closing the cycle and finish the whole review process.

This makes the system fully contained and automatic, and above all more or less idiot-proof: it requires only forms to be fully understood (and those can be made to clarify directly there) and with RB recording everything, whoever is the owner can recover any information in case there is disagreement. No need for special codes to learn, no need to become familiar with a website (forms have no science to them, you don’t need to post your review in any place you aren’t familiar with, you don’t need to be in any place you might object to), and no need to choose any one place to be the main base for the group, if any place. Keeping tabs of both places would be less of a chore and more of a personal decision, so if you want to keep using both places you don’t have to worry about anything other than filling your forms.

Beyond that, there are many particular functions that this arrangement permits which are simply not possible under your proposition: if a reviewer decides to drop a story for any reason (or you want to add a sort of time limit assurance, like for example a reviewer says to drop his claim after x days) , RB and the scripts assures you can develop a system to recover it automatically and mark it accordingly to see if someone else decides to help them because of it; you can set up for the RW spreadsheet to have the stories removed within a time limit after the review is made, just to eliminate clutter there as well; as I said originally, you can set it up so it automatically emails Writer A so he knows that he got the review (and, if you ask the reviewer to put an email, who to contact); you could even implement the karma system in a far better, and automatic, way, capitalizing in the functions located within the spreadsheet system to count the number of reviews and modify things accordingly to whatever you think karma should do. Can all of that be done with the Tinyboard idea? Can the Tinyboard idea even keep records of anything, seeing how you have a section in the spreadsheet that keeps tracks of the bad apples for the sake of newcomers? Word of mouth? Furthermore, what about having a password which uses an sheet in RB which stores the value and compares it before you can modify things?

I can clarify anything you want, but this is the basics of the proposal: forms as the main way to interact with the spreadsheets, the spreadsheets communicating and transferring the information around and cleaning themselves up as triggers are made, and a simple organization which abstracts most of the organizing from both the reviewer and the writers hand into the spreadsheet (I’m resisting the desire to call the different pieces model, view, controller, databases, and user controls because they aren’t quite the same, but I guess you can see why I want to do so).

Oh, also, there is the chat function for everyone to communicate through that, should they decide to all hang out within the spreadsheet, or just communicate wherever; the spreadsheet and the chat will be effectively independent to each other except for bugs.

Or even better: there are various different review groups that which would probably enjoy knowing this exists and that they can use it as well, and the fact it will only be forms means they have no learn nothing to use it. On that note, this means they probably will interact with due to sheer proximity, making this be easier to strengthen relationship between the various groups and increase the number of reviewers by the factor of ease of usage (not learning about things which aren’t related to reviewing, like how does an imageboard work, or what is the right code for the various things you might need). This also means that this would become embeddable: two links, one for RW and one for RR (or to the necessary forms) , is all what you would need to access the system, so you could place it on your user page of any website and it would require no more explanation than themselves. Can Tinyboard help with that?

I believe keeping it with google docs, and capitalizing on the many functions you can run with it and other abstraction benefits they made specifically for these sorts of things, is the best path to take, and I think the possible expansions which I describe, the fact this makes the automatization be even more effective, and the fact it makes it more open will only lead to an even better system.

Full disclosure: I got plenty of help thinking all of that out.

So, there, that’s my counter proposal.


Here will be the relevant documentation:

Still have to get it, but I offer in the meantime these stack overflow questions:

- http://stackoverflow.com/questions/4509336/how-to-copy-a-row-from-one-google-spreadsheet-to-another-google-spreadsheet-usin
Where they describe sending specific pieces of information (a row, in this case) from one spreadsheet to a completely different one by means of a script. This sort of thing can be used to modify single cells, as defined here https://developers.google.com/apps-script/class_range.

- http://stackoverflow.com/questions/10726806/google-docs-spreadsheet-app-script-copying-data-between-spreadsheets-without
Where it describe a similar collection method, where the SpreadsheetApp.openById() allows you to take any one sheet and take it anywhere else. Or so it looks like.


And, to answer Demetrius last question:

My uncle is responsible for the maintenance of the internal network, database, interfaces, and a bunch of other things in the company he is in. He is normally really busy (for example, he just took a plane last night to work on some server the people were the server is haven’t been able to figure what is wrong). I brought him the problem, told him what I understood, he then told me to give him some time to read, and then he explained to me how to separate each of the databases responsibilities and said it should be doable.

Don’t think he will be helping all that much even if he wanted to, though, but he seem to believe it wasn’t impossible. What you need to get from that is this: he just read the documentation (how much, I don’t know) and told me that. I have no programming experience except some very basic C, so I’m trusting that he didn’t misunderstand something. Hope that clarifies things.
This post was edited by its author on .

!!Fluttershy ## Mod 1011

File: 1352905089586.png (288.94 KB, 600x700)

>>1005
I edited #Discussion in your OP, apologies if it's not what you wanted, your report was a little vague.
Do report your thread again if you want other modifications, and have a nice day.

1012

File: 1352909338520.png (33.81 KB, 231x447, Sum_Pony_rears_up.png)

Thanks OP! TTG deserves a break from my rabble-rousing.

>>1010
And thank you! That is awesome. I am sincerely glad to have been proven wrong. Before I begin work on the tinyboard-integrated solution (well, I sort of have already but haven't done much since*) I'll see how far I can get with the information you've provided me.

The discussion so far:
>>929
>>930
>>935
>>936
>>938
>>939
>>941
>>942
>>955
>>956
>>958
>>968
>>969
>>976
>>977
>>981
>>983
>>1004

* I was planning to add a field to the post table(s) for distinguishing threads as type "service". Then, when I went to the Post and Thread classes, I noticed that not only was there a buttload of redundant code, but the constructors for those classes took over 27 args that were basically the associative array returned by PDOStatement::fetch(), indexed at each column and manually placed into the argument list. I couldn't stand that; it nearly made me retch. So, Monday night I did loads of refactoring so that the argument list is simply that array plus three more optional arguments. That way, adding fields to the posts table / attributes to the Post/Thread models in the future will be way easier; column names map directly to attribute names in those classes. Soon we won't have to go through the code and manually append arguments at six locations whenever adding fields to posts. I also found a bug or two in Tinyboard itself. That's why I love XDebug and Netbeans.

Anonymous 1024

>>1012
In all fairness, you weren't wrong, the script necessary to do that can't be made with only in-spreadsheet code. That said, you can get some fancy controls to sort or remove information in the different sheets as I mentioned.

Also, I just remembered something that was mentioned: there could be multiple RW and RB spreadsheets communicating with the RB, but I can't remember the architecture of that.

!SumPony41s 1041

File: 1352967237176.png (40.5 KB, 708x794, Sum_Pony_soon.png)

>>1010
Good to know.

I take one thing back (sorry, change of mind), however. Since I have a clearer picture of how to proceed with developing service functionality into Tinyboard than I do of developing in Google App Script, not to mention more experience with PHP, I'm going to attempt my idea first — and in this post, I will write it out in more detail for the sake of brainstorming.

> there is a ton of programmers here and I'm sure they'll find which one does the job better (as in, more efficiently).

I think that any measure of efficiency would have to be about the usability of either solution (since it's all humans interacting with things), so I think that anyone could give the same measure of useful feedback regardless of their knowledge of web development. Nevertheless… Since Macil won't be available for a while and I'd like to get started on this Friday, I decided to include technical details. Any feedback from programmers would be appreciated.

Life Cycle of a Queue Item:
(in the idea I propose)

First, let us assume that a user has created a thread designated as a "service" thread. Such a thread is created by checking a checkbox in the form to create a new thread. When that checkbox is checked, another checkbox appears for it being a "private" (i.e. single-maintainer) service thread. Assume in this case that it's unchecked.

1. A user makes a request to the OP of the thread by checking a box in the reply dialog / form designating the post as a request, which only appears when replying to a service thread.
2. The request shows up in the queue, a collapsible box at the bottom of the thread's OP.
3. A reviewer uses one of the links next to it in the queue to get a properly formatted claim-request link. That, OR: the reviewer chooses to review in a different thread and uses the same citation format there
4. The request disappears from the queue, but shows up in the second part of the queue, for in-progress.
5. When the reviewer posts the review (and it contains a fill-request link) the request moves into the "done" part of the queue.
6. The original requester comes back and leaves feedback for the request-filling post, or a mod per request comes by and removes it from the queue if it has been too long. When leaving feedback, the password must match that of the original request post.

If it were a private review thread, it would all work the same, except a check would be performed of the review post's password, to see if it is the same as that of the thread, and review/claim posts citing posts within that thread won't work outside of that thread.


Tentative WIP plan for implementation
I've been studying the source code while brainstorming. What I've come up with so far:

In the database,
- The posts table has a new column, "type", for distinguishing service threads and request posts.
- The cites table also has a new "type" column for distinguishing it from other cites as being a part of a request's lifecycle
- A request is designated as filled by changing its "type" field.

In posting (pretty much all happens in post.php),
- Claiming a request for filling, reviewing or leaving feedback: pretty straightforward; the link format will go into post.php where the insert of the cite happens. A post will be permitted to fill only one request, so it won't be possible to bomb the queue by filling all the requests and then leaving feedback for that post. Also… Abuse of the system in general should be against the rules.
- Request-filling: if the thread is designated as a private/non-open review thread, the password is checked against that of the thread wherever a claim or request-fill is attempted ('thread' in $_POST has its ID). For tag-team threads, the password could be shared.
- Leaving feedback in particular: if the included password doesn't match that of the post of the original claim (a join that uses post data for feedback -> cited post -> that post's request-fill type cite -> original post can be used to pull it up) post.php throws an error.

In thread/post building,
- The "build" method of Thread will have a conditional statement wherein if the thread is a "service" thread, it will perform an extra database query (unfortunately, I can't see any way around it) to retrieve information about the queue in that thread.
- The post_reply template will be modified include javascript buttons (fill request/leave feedback) to put the link format (i.e. >>rNNNN) into the reply box in the case that the post is a request or filling of another request.
- A collapsible area for displaying the queue will be added to the post_thread template, and templates for queue entries will need to be built
- the postControls method includes moderator buttons for manually un-filling requests, marking request filling posts as "old" and other necessary clean-up actions

That's it for now, I'm le tired.
This post was edited by its author on .

1044

File: 1352986117323.jpg (27.22 KB, 462x462, 9842618_gal.jpg)

Okay, so I said I'd weigh in on this… but it's gone way above what I can comprehend. Personally, I like the board-integrated plan, but that doesn't solve the problem of people posting on Ponychan. Anyway, I'm neither a maintainer nor a particularly smart person in this area, so I'll bow out gracefully.

By the by-and-by, >>938 and >>955 were me.
This post was edited by its author on .

Anonymous 1045

>>1041
So you are going to make the tinyboard idea, then go to develop the Google one, and then replace the former if the Google idea pans out as the better choice? It makes sense considering the tinyboard idea sounds like its more like modifying just a couple of things, while the Google one would need making the whole cogs themselves.

On the other hand, as I said, the Google one can do far fancier and automatic stuff (emailing people once they get reviews is actually the thing which makes me really like my concept, the greater simplicity was what sold it), so it's more of short-term—long-term situation as I see it.

The fact it is also website agnostic also appeals to me, because it means anyone can use it. I think we all know imageboard aren't as intuitive as we would want, as how must people come saying "how do I imageboard."

Anyway, good luck with that, maybe get some to look more into the Google Script part in the meantime?

1046

>>1045
>the Google one can do far fancier and automatic stuff
Well, working with Tinyboard you can do anything that PHP can. Sending emails is well within that scope. (And I know that this server's mailer works fine because the write-off site uses it.)

1047

File: 1352994808848.png (33.17 KB, 174x169, AweSumPony.png)

>>1045
> the tinyboard idea sounds like its more like modifying just a couple of things, while the Google one would need making the whole cogs themselves
To be fair these are a significant number of modifications in multiple places. It would still be a challenge, just one that I have a better idea of how to meet.
> The fact it is also website agnostic also appeals to me, because it means anyone can use it. I think we all know imageboard aren't as intuitive as we would want, as how must people come saying "how do I imageboard."
A goal can then be to tweak the interface to make it easier to understand, i.e. by adding tooltips everywhere and whatnot (and as Roger mentioned, one has the extreme flexibility of coding directly in PHP/HTML/Javascript). AFAIK you can't really do such things in a Google spreadsheet form; you're limited to the help text on each field. Plus, there's the whole deal of them having to go off-site to request something they're going to receive on-site. I agree with the appeal of its website-agnostic property though, which is why I'm still going to attempt it, although it's a lower priority.

>>1046
> Well, working with Tinyboard you can do anything that PHP can. Sending emails is well within that scope
Whoa, I forgot all about emails. Yes, I think I'll work on email notification. All it will take is uploading PHPMailer and building an email template, really.

>>1044
> that doesn't solve the problem of people posting on Ponychan
Is it wrong that I don't see that as a problem? If they find such features useful, they'll move here. If they don't, they'll make do with Kusaba-X and Google Docs because that's simply what they would prefer.

<ymmmmmQmmmmmmgaaa,
._awQQQQQQQQQQQQQQQQQQWQma,_,
amQQQQQQQQQQQQQQQQQQQQQQQQQQQQgc
=wmQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQL.
_vQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQm,
4WQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQm.
_3QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQWm,
_wQQQQQQQQQQQQQQQQQQWWBWWQQQQQQQQQQQQQQQQQQQQp
.,QQWQQQQQQQQQQQQWT??"` -?$QQQQQQQQQQQQQQQQQQWc
:QQQQQQQQQQQQQWD!` "?$QQQQQQQQQQQQQQQQm,
:QQQQQQQWBHT?"` WWQQQQQQQQQQQQQQQQC
:[email protected]! WWQQQQQQQQQQQQQQWQk
"$QQW` VWQQQQQQQQQQQQQQQQm,
"XQ[ ._%;` "$QQQQQQQQQQWQQQQW;
jW; ._}`__%"`__. ?QQWQQQQWQQP^~~?(
-$k /^ _%-..jQQQmgs_a_,. )QQQQQQQQ[_"""+%:
-$C `amW(:()B$WWWQQQQQQmw, ]QQQQQD(:^. ]a
"(_mQWE+:= ~?TTTT9WWz"= :QQQWP` E
jQQW! +- _, +=!: :QQQC =7<. v/o
jQQQws, , _, .{ymmwa|a+"~ ""! -` )[l
:[email protected]! -^<v, {; -Y"^- _;-^- {, .d[=
]@` _yWBB[( \,_>! . =( +~ >
[email protected]! .;> )s+` _=
-{*=__}{v[ .}
=2`- <`] __. _2
< ='./ "!;-"<, _,+YQC
<( )+.u` . =. -(. _ )( jQ`
:` = )!: _/"~~^` +, ). =(.mk
=; -.-=7` -` ):( ; =2.mf
{ <+ _a;~+awwwywc |: > v<Q[
s ); .="+<<amVP??F?Z$to:..( )]B'
-< 1 =XmmU!"-|.s<wgmQm21:.=- )=;
-( <;5Qm;_aawmQQQWQDY' =_7 )=;
-s +>[email protected]?<s7"_} ==' ):;
{,-}<-YT()!"~ _/+ ./> _}.;
">:s(_,____="~ %\+ _( =
-+=. —. .%`+ %' v.
-sc - -' % -\.
]. -` )>
) % |=.
.c _} =c<,
-+_. ._=+~ 3;+,
_q!<a+! )o -=,.
.> < "> ?( -"s.
.} .c =( <
.% "= %'
-` -` 1
.:
This post was edited by its author on .

Anonymous 1050

>>1046
True, I hadn't considered that, but I think it would involve even more modifications to all parts, methinks. I guess you would have the person make the request, who then has a record of the email, then the new script would look at what post it is responding to and see what email is there to then make the email. Something like that?

>>1047
>To be fair these are a significant number of modifications in multiple places. It would still be a challenge, just one that I have a better idea of how to meet.
What I meant was that one needed you to learn the ropes and make the tools, while the other one you probably already have code you could use as a template. I don't think there is too much Google Docs Code out there which to make this.

>A goal can then be to tweak the interface to make it easier to understand, i.e. by adding tooltips and whatnot. AFAIK you can't really do that in a Google spreadsheet form (though you can add help text).

Seeing all the people who don't bother reading the ones on other chans makes me doubt they will end up being all that helpful. People just look at chans and start freaking out. Forms are easier to wrap your head around because they need no special codes, which is also a selling point for me: the end user has less to learn. I hope my pessimist is wrong though, but previous places (4chan/Ponychan/XXX, where people asking questions that they can find easily without needing to ask) make me keep my jimmies off that bet. The rustling would be too large.

>Plus, there's the whole deal of them having to go off-site to request something they're going to receive on-site.

Well, seeing how the actual reviewing occurs off-site (google docs, fimfiction, DeviantArt*shudders*), this doesn't seem like all that much of a point. People seem to keep posting in threads for the sake of tradition than actual effectiveness, because doing within those places gives you a notification faster (Fimfiction offers private messages and comment; Google docs offers notifications and just letting the pre-reader add his review at the bottom), and in Google Docs you have less effort to do to point out the errors. I don't think I'll be the first one to point out that the only real think that happens in thread that needs to happen there is record keeping, which is why the review threads were made to begin with as far as I've been told. Private reviewers are actually a good example of this: they manage to keep track of things just fine within those places directly.

>I agree with the appeal of its website-agnostic property though, which is why I'm still going to attempt it, although it's a lower priority.

Does make sense, it is your time after all. I am glad you can see the many benefits that making it website-agnostic would bring, but if it would need you to work day and night for months to make it the effort might not be worth it. Still, from my ignorance of the Google Scripts capabilities, it sure sounds like it could do some pretty cool stuff, like generating review documents all on their own (http://www.youtube.com/watch?v=OdoDuZfP6a0 / http://stackoverflow.com/questions/12320580/can-scripts-write-read-directly-to-from-google-document), making the system be fully contained. And unless I'm not understanding something, you could even give them the review as a google doc directly to them (no need to have it store space in your own drive) after reading this http://stackoverflow.com/questions/10796464/transfer-ownership-of-a-file-to-another-user-in-google-apps-script, or allowing you to trash it after some time if I read this correctly: http://stackoverflow.com/questions/13259306/google-script-settrashed-only-working-for-document-owner.

Yes, I'm stupid and easily excited.

PS: Also, Google Talk bots. Use them to keep people updated with information as new stories come in, or when milestones have been reached. Google API based can do a lot of stuffs from a single account.
This post was edited by its author on .

Anonymous 1051

I have an aside I'd like to inject, if you all don't mind.

Certain members of /fic/, as we see in this thread, believe using Tinyboard they can implement a better functional system and upgrades for the /fic/ community. (Or simply do something with Gdocs, outside a site altogether.)

This may make syndication obsolete and/or unnecessary or unnecessarily complicated. Support for syndication seems low at this point, as the PRs seem to be of the group opinion they will refer to wherever the reviewing resource is, and it seems the bulk of reviewers are enthusiastic about a move and its potential, to say nothing of a fresh start on which to grow.

The simpler option of moving, in accordance with the far majority input in the initial discussions/poll, is now being weighed against the concept of syndication. (Or simply using docs, with a site as a sort of home base). With the former, the efforts of members and coders can be put towards specific upgrades and functions/systems. Should syndication continue to be pursued, or should it be shelved in light of this context?

Discussions on it are likely to occur very soon, and if support has waned to the point of it being a triviality, it would probably be best to forego it and its complications. So tl;dr do we still want to pursue what is likely a pipe dream or have everyone focus their efforts on a clean move, coding-capable individuals like Roger and Demetrius and others put their efforts towards functions and features here (or Gdocs, again), and move on? A quick round of input would be a good idea for this. Let anyone who has any know.

Anonymous 1053

>>1051

In the event that syndication is improbable and highly trivial to accomplish and implement, the likely recourse would be to stick with the move and remain here.

The only other option would be to create a separate website designed exclusively for what /fic/ needs and have the *chans link to it, but that's long since been a pipe dream.

Anonymous 1054

>>1053
>a separate website designed exclusively for what /fic/ needs … long since been a pipe dream.
Unfortunately true.

>improbable and highly trivial to accomplish and implement

That seems to be where we're leaning. The initial push for it was largely on the backs of question about the PRs referrals, something cleared up, leaving the reasoning for it rather thin. Having the errants threads from both sides being shown through this syndication system, I believe, would only clog things up further, and the differences in response time and moderation may leave people confused. Not having one set of firm guidelines (or getting two different places to have exactly the same ones) seems over complicated and getting human behavior to coincide like that seems implausible. On top of technical matters, the human entanglements and complications put together would seem to be more trouble than it's worth, requiring constant work. Having one space for a dedicated group of reviewers, and one as a more general, casual place for fanfiction showcase and discussion, would at least to me seem like the far more easy and worthwhile thing to pursue, especially considering that it leaves the likes of the coders here, as well as Demetrius et al, to dream up and implement what sound like killer apps. Hence, the question here for reviewers as to whether it should be shelved indefinitely and efforts better focused by all parties.

Anonymous 1055

>>1051
I honestly believe making this be only for /fic/ to be stupid.

The syndication idea would make sense much more if this was a site-wide effort, with the intent of having equivalent content be together should the users want that, and thus letting people have a choice of what they want.

Just give a warning saying the marked threads are from other websites with different rules, and then you can actually have something which will matter. Like an /all/ that actually works, is what I'm getting at.

>>1053
Pretty much this. The website designed for /Fic/ apparently has been an on and off things, so I don't know how much effort was really put into it, or if people just went "fuck this."


>>1054
>The initial push for it was largely on the backs of question about the PRs referrals, something cleared up, leaving the reasoning for it rather thin.
I thought it was based on having people who would rather not move (Azusa) having the opportunity to just use whatever place they wanted.

Anonymous 1056

>>1055
>I thought it was based on having people who would rather not move (Azusa) having the opportunity to just use whatever place they wanted.
As far as I remember, that was as side matter. Since the few initially in opposition, Azu, Demetrius, have dropped opposition (the latter in fact enthusiastically so), that also has been removed as a reason for doing it.

>I honestly believe making this be only for /fic/ to be stupid.

I agree. Though, and since, two complete sitewide syndications is even more of a complex mess of technical and human matters (in terms of cooperation and willingness), and in fact the small number of people who even bother with /all/ and and the silly way it displays threads, it seems even more of a pipe dream.

>Pretty much this. The website designed for /Fic/ apparently has been an on and off things, so I don't know how much effort was really put into it, or if people just went "fuck this."

GUMMII has had a lot of work put in, I believe, but it is/was still many months (year? more?) away, and eventually was just shelved as well. Having a present, tangible opportunity here in contrast has been a difference maker in terms of support.

Anonymous 1057

>>1056
>As far as I remember, that was as side matter. Since the few initially in opposition, Azu, Demetrius, have dropped opposition (the latter in fact enthusiastically so), that also has been removed as a reason for doing it.
I say that because there were people to quick to point out that the prereaders response wasn't important because you can't point people to an empty house, unless you are trying to be a dick. I assume that, seeing how it was crazy that prereaders wouldn't just start sending people to mlpchan if they actualy wanted to help them, the discussion focused on getting those still behind on board.

>I agree. Though, and since, two complete sitewide syndications is even more of a complex mess of technical and human matters (in terms of cooperation and willingness), and in fact the small number of people who even bother with /all/ and and the silly way it displays threads, it seems even more of a pipe dream.

From what I understand, the main issue was that the way the boards are generated would have made it necessary to run two or three scripts to make /fic/ only syndication possible.

>GUMMII has had a lot of work put in, I believe, but it is/was still many months (year? more?) away, and eventually was just shelved as well. Having a present, tangible opportunity here in contrast has been a difference maker in terms of support.

First, I've heard of Gummii, but mostly that it was in the works and nothing more. I guess more stuff happened in the background that I could hear of. Second, this makes me wonder if this could have been done in Ponychan, and if could have, why wasn't it attempted.

1058

>>1055
>>1056
>>1057
You should talk to Demetrius if you want a full, informed answer about Gummii.

>Second, this makes me wonder if this could have been done in Ponychan

Coding is harder in it and everything has to be vetted by the administration, which moves at a pace best described as "glacial". Demetrius has already established a rapport with the admins here and is actively helping them tidy up their code. Collaboration, from what I've gathered, is far easier here than on Ponychan.

Anonymous 1059

>>1057
You have a point on the first part. It was just that the initial suggestion for the idea came about because of it, but I guess you are right that it gained any support at all because of those not yet on board at the time.

I believe you're right on the second part as well. Still pretty unlikely 2 separate sites would become one complete cross-stitched union.

To the third, yeah. There was quite a lot of discussion on Gummii but it's not likely to be a factor. As for why it hasn't been done there, the simplicity of what Demetrius, Roger, et all find in Tinyboard's code for possibilities, as well as things like: the built in scripts actually working with the features like hide and edit (they don't on PchanX/PonyupZ, the auto-refresh and other features of them necessary to approach the functionality of this aren't compatible and at the very least, require exiting/reentering a thread or refreshing every reply.) Further, Kusaba is also relatively obsolete, having no further updates for over a year and no longer is really supported. Last check, there was a blurb about how they "hadn't yet abandoned" work on a new version - almost a year ago. The last actual work on it seems dead. It's no longer considered active. Tinyboard vastly simplified the messes of code of it and other imageboard softwares, Futaba et al, and streamlined possibilities, and is an active work fully supported by its developers, updates still coming in.

>>1058
This as well, on both counts.

Anonymous 1060

>>1059
>I believe you're right on the second part as well. Still pretty unlikely 2 separate sites would become one complete cross-stitched union.
A bit of reading has lead me to believe it shouldn't be impossible or protracted, however. Also, it would be the first steps in making the Cold War between the two places stop. I'm sure someone out there can make up more possible benefits, but having both websites say "ok guys, you want to see the content of the other chan? Click here and you can see it, but be warned they are outside our control" is a good step for all.

At this point, the only real technical issue that has been brought up is a non-issue if the coding is made standard, and the idea that Kusaba can't be modified to fit the needs doesn't follow from the fact Orange has basically overhauled the code to be better suited to his (and the users) needs. It might take some thinking, but the lack of will is pretty much the only reason why I can see this being a problem.

>All the list of technical issues and Celestia's update speed.

I am under the impression the latter are noted and solutions are in the way, or already implemented, and the former has improve massively, while the website apparently now has more than just Celestia knowing the code. That it has to pass through Orange before being implemented seems a rather petty grievance, I doubt Macil just takes code and pastes it in because of the goodness of everyone's heart.

Plus, I really doubt he wants to put all that effort just for /fic/, which is again a tiny community whose motto seems to always be, "FUCK PONYCHAN…. but we are still gonna stay." Added to Ion's inability to be endearing and non-conflictive, and you have agree with Orange feeling you guys are wasting his time. The whole thread over there has been a bitchfest at Orange. Justified or not, that hardly makes for rapport.
This post was edited by its author on .

1061

Syndication is, to me, not even a very good idea in theory, let alone practice. I've yet to see any enthusiasm from any of the parties involved, and much less so from those who would be tasked with the actual implementation. Even so, whether or not anything of the sort will come about is, I think, beyond the scope of this thread.

What needs to be identified here are precise problem definitions. What tasks does the Training Grounds perform? How could its operation be better handled? We could talk till the cows come home about how much of a crutch imageboards are, but what is the proferred improvement?

As Demetrius said, you don't need to be technically inclined to answer these questions. Think about the current functioning of the TG, and then offer how it might be improved.
This post was edited by its author on .

Anonymous 1062

>>1060
Standard coding between two sites with different imageboard softwares altogether doesn't seem like an insignificant matter. Nor, for that matter, has there been any real call by users for some grand union (nor do many people use the existing system of /all/ in the first place, at last time I heard, a fraction of a percent. It's really a non-issue.) That still doesn't solve the inherent human confusion of such a thing, even if just for the small handful of people who would theoretically use it. It's never even been brought up, and I don't see why it's come up just now.

>I am under the impression…

That may be the right impression. But we've seen spikes of activity from him before, only to quickly fall back away into hibernation and letting things pile up until they are in full disarray, only to rouse from slumber when there is a mess and deep discontent, and then only to just do the minimum to prevent losses to the site. You can't really disagree that that's a big part of why some people don't exactly feel like being "endearing." We've been down this road before, only to be disappointed time and time again, or even (if you know of certain behind the scenes situations) be lead to the near brink of complete shutdown (on several occasions, and rather recently.)

Overhauling a dead and obsolete system so that it can still shamble along like a Frankenstein monster (Frankenstein being his own term) is not exactly an argument for continuing to do so. One can only tune up a Ford Pinto for so long before it's time to get ones self a new mode of transport.

And you're right, he doesn't want to put in that effort just for /fic/ - also not an argument for him. Nor for /fic/ syndication, which is what we are discussing - not sitewide syndication (a pipe dream, let's be frank), or some sort of grandiose and delusional unification theory. Let us deal with the issues before us, namely -
>>1061
This.

The continuation of the majority and majority-following-the-herd's wishes for the move and the new environment, followed by thinking about how it can be best be made to suit the /fic/ review community in its new home.

!!Applejack 1070

File: 1353035871060.png (313.91 KB, 780x720)

>>1061
>I've yet to see any enthusiasm from any of the parties involved, and much less so from those who would be tasked with the actual implementation
This is something of a concern for me.

It feels a bit like the few who were interested in the idea in the first place kinda sparked a bit of nervous energy just to "do" something and we moved inexorably towards it, even though it really might not be what's wanted. And then it become a bit of a frustrated urge for people to talk about it anyways. We're busily working on things mentioned in this thread, as well as other site things, and if the interest in this has fallen through, I'd like to know before we proceed and get ourselves tangled in a complicated project that's unnecessary. If everyone could let me know how they feel about it, I'd appreciate that. If you'd prefer to talk to me one on one, we can do that to.

>but we are still gonna stay.

IIRC, taking into account Azu's move into the "for" category, Demetrius move from neutral to for, and Pav having his concerns alleviated, the unofficial poll would be left standing at something like 22 for, 3 against and 12 following the majority, for 34 wanting or willing to 3. You can't find much more in the way of majority support than that. For now I have to take that as the default stance, and we'll look at everything else from there, proceeding as planned with the intended transition to here until otherwise informed, with the understanding the cleaner, sharper and less dragged on it is, the better it is for the unity of the group.

Demetrius!WDFBcC5x22 1071

Wow, lots of discussion. Also, I'm at the office, clocked out, on a proxy out of Sum Pony images.
>>1050
Yes, the 'email' field is also in the posts table, so retrieving the email address is a trivial matter.

>>1053
> This may make syndication obsolete and/or unnecessary or unnecessarily complicated.
Not necessarily. If syndication worked entirely via simple cross-site retrieval of thread documents (so that threads on a different site were "read-only" on the site in question) it would be the same as if such new features weren't there, because all that really needs to happen is grabbing the content after it is generated and displaying it on a different site. Integration of such a thing into the existing board software, however, is what I think might be challenging, but I'm pretty sure I'll be proven wrong soon enough.

>>1055
> I honestly believe making this be only for /fic/ to be stupid.
I agree (you're referring to new features on mlpchan, right)? In fact, it would be more effort to make the changes apply only to /fic/; the files I mentioned would be edited in the process of implementation are used site-wide. :-P

It's also why I used generic terms like "services" instead of "reviews".

>>1056
>>1057
I went overboard with that project. I did enjoy myself and developed one kickass boilerplate for a web app where all content is loaded asynchronously. Thing is, it wasn't getting any closer to completion. So, after some kicking around, I decided upon the quick and practical solution of joining Macil and doing work on mlpchan, since I'm pretty sure I could modify Tinyboard much faster than I could build an imageboard, a queue system and a fanfiction publishing system from scratch (which is the overly-ambitious goal Gummii).

>>1060
> I doubt Macil just takes code and pastes it in because of the goodness of everyone's heart
Quite.

I admire that about him. I have faith in him. The first commits I pushed to my branch on the mlpchan repository he examined carefully and actually took time to give feedback on. I don't know if he's merged my changes into the main branch yet, but that's because he's busy. It's a good thing that he is very cautious with regard to security.

All things considered, I'm already enjoying working with him.

Anonymous 1073

>>1071
>Yes, the 'email' field is also in the posts table, so retrieving the email address is a trivial matter.
That does simplify things greatly.

>Coding of syndication

I thought syndication was simply letting the board pages have the same threads side by side, but when you clicked on one you open the thread in their respective place (and everyone knows that most of the time the quick reply option is BS in both chans). Doing that, I think, should be a matter of retrieving specially marked content. But as it was said, actually making this retrieval might not simply take selecting a box, as I haven't heard of a similar thing anywhere else.

No, I was talking about syndication. Doing a syndication only for /fic/ would need more work as you try to make it work with the normal generation while still syndicating. If you syndicate everywhere, only the main board creator file should need to be modified. I think.

Which brings the question: is GUMMII dead?
This post was edited by its author on .

Anonymous 1074

>>1070
Well, I think it is mostly that people see you and !!Celestia acting like children and are getting the position of why bother?

I frankly like the idea of syndication on the abstract, because it allows people to trickle in from Ponychan (sorry, but this place is still pretty empty by comparison).

Then again, I want the whole reviewing system removed from all websites and run as contained as it can be done within Google Docs (which I am learning can do more and more stuff every time I begin to read the documentation, such as creating documents filled with the review and then transferring ownership of this to the reviewee, all while having a bot tell people what was claimed or through google chat; it's a pretty nifty pile of stuff you can do with Google Scripts), so syndication wouldn't be needed as all the review needs (except for socialization, but there is a document chat too) would be contained in a chugging robot made up of google doc parts, so take my opinion over it as you will.

!!Applejack 1076

>>1074
I can see that, certainly. I think as Demetrius implied, that kind of self contained document system will be worth looking into in the future, and you commented that it would be somewhat like building from the ground up, while he's anticipating relatively easily building something worthwhile through Tinyboard to use.

Though as to your point on people trickling in, that sort of implies it's simply a transition period in order for people to come to use the better system, making syndication a permanent solution to a temporary problem, one just as readily alleviated, likely, by a clean and clear move with visible notification to those who come through, as far as I can tell.

To the last part, it's been fairly calm and collected here throughout, without any needless dramatics, as it should be. I get liking an idea in abstract, but I haven't seen a lot of others saying they do, and certainly some who say they don't. And abstractions are one thing; readily pursuable and long-term solutions with concrete and relatively un-entangled results are another. There is a certain level of enjoyment people get from the imageboard system, and it does contribute in intangible ways to the community. Creating the best possible imageboard environment, on the best possible software with the best possible features and functions, is what (in my own opinion, as a non-reviewer) the task at hand should be.

The choice of where that is has largely been made by a clear and decisive majority. It's a good idea to discuss possible futures with self-contained systems or non-board websites, but those seem very long-distances from now, where people are actively working on the community in the here and now, in a space that tells them, 'this space is yours, not only can you craft and mold it as you will, but we will do everything we can to help you to do so,' rather than 'this space is ours, but I guess we'll look at what you want and maybe work with you, but really only because it took a year of wrangling and because we were backed into a corner, and maybe even we'll forget about this shortly, and this space is still ours, you just live here.'

As illustrated here, http://mlpchan.net/fic/res/525.html#1075, maintainence of separate spaces brings its own confusions, and in the end if all the reviewers (as illustrated by the 34-3 majority) move into one space, syndication then becomes solely so TTG is in two places; basically, the same thread for the same purpose unnecessary duplicated and an entire system built just so the duplicate thread is visible. I just have questions about how useful it is to put time and effort into that and now what, it seems, people advise can be done in the alternative and wouldn't be better served with a clean start and the growth of those functions.
This post was edited by a moderator on .

1079

File: 1353043485633.png (112.83 KB, 480x360, Austin Powers.png)

>>1073
> Which brings the question: is GUMMII dead?
Cryogenically frozen. I sunk a lot of time into developing it and I'm not letting go of it. My only fear is that when I thaw it, it won't be relevant any more. The best chance it has is simplification; I have a tendency to over-think things. It needn't be as sophisticated as IP Board, I keep having to remind myself.

To be honest, in regard to the spreadsheets, it all seems like it would work more easily than a dedicated custom-built app, but it doesn't seem like it would be as much fun in the end (and those of us who've been around before the IRC will remember how terrible the spreadsheet chat was for socialization or constructive discussion). An all-encompassing site that has all the features needed to perform reviewing efficiently and provides a place to socialize at the same time is an ideal I had in mind when I started the thing. The spreadsheet is a sort of…machine, where you put something in, get something out. It's less community-oriented and more like a private dating service or something (where a request would be a personals advert in this analogy).

Anonymous 1080

>>1079
Curses.

And I don't think that aspect of it can be ignored, the social dynamic.

What you're working on here, that will, as much as is possible on an imageboard, pursue the goals you had in mind with GUMMII?

Anonymous 1081

>>1076
Ehmm… what?

1.) Not trickling down from /fic/, trickling down from ponychan, as it's clearly written there. This place number of users is far smaller than Ponychan's, and /fic/ is always looking for new people, which is the point of that. Did you misread or something?

2.) I believe you meant the first part? The last part is speaking of Google docs and how syndication wouldn't bring any benefits if the Google Scripts version is made because there wouldn't be the need to feed from another imageboard. You could make so that you don't even need to post reviews here, or anywhere, so the person requesting receives it. Also, the liking of the idea in the abstract was part of the second paragraph, which dealt with this place having less of a candidate pool because of who came over from Ponychan and its small size.

If we assume you meant the first part, no dramatics, I have seen you both quarrel and quibble for some time now and nothing else could describe it more accurately, specially if one takes both of your attitudes into account.

Lastly, you seemingly are making the assumption that /fic/ chose imageboards, and particularly your board, because they like imageboards so much and think they will not be able to do without, while the fact is that even Demetrius used to dislike imageboard with a passion (why he now wants to stitch the whole thing into an imageboard bothers me a bit, but I can't know his final motivation for doing that) and I know Samurai still hates the fact he didn't get people moving when he had the chance because imageboards are not conductive to what reviewers do. His words, not mine.

As for the decision, the decision was to move to see if the benefits offered by the board could tide it over while a truly good solution for the problems of reviewing would come along. /fic/ pretty much said it had no allegiance with any website, and I get the feeling that remains unchanged. Should a better solution appear, /fic/ will leave and take its work elsewhere. You are aware of that, right?

>>1079
Looking at most of the threads in ponychan, either the socialization was erased, or it happened outside of the imageboard. So, I don't get your point? The IRC is the place for socialization as far as I can tell, and the only site-wide activities are Roger's write-offs, which have their own web-application (which used the threads in ponychan for advertisement for the most part, as proven by the inanity of some of the comments…).

>>1080
GUMMII had a socialization aspect? I thought it would just be like a fimfiction, but with review queue, and some fancy score keeping, and actual standards.
This post was edited by its author on .

1083

File: 1353044340000.png (337.67 KB, 762x1048, gummy__g_man_by_super_zombie-d…)

Edit: stop spelling its name in caps. It's not an acronym. It's a portmanteau of Yii and Gummy, the first thing that came to mind, and it just stuck, as silly as it was.

>>1080
To some extent. Like I said, quick/practical solution.
>>1081
> Looking at most of the threads in ponychan, either the socialization was erased, or it happened outside of the imageboard. So, I don't get your point? The IRC is the place for socialization as far as I can tell, and the only site-wide activities are Roger's write-offs, which have their own web-application (which used the threads in ponychan for advertisement for the most part, as proven by the inanity of some of the comments…).
Socialization also happened in the write-offs, the collaboration projects, the author collection threads… /fic/ was never entirely about reviewing, though apart from community activities that's mostly what it did, when it wasn't chewing the asses of hapless newcomers. Also, don't you think it would be useful to be able to make reviews easily visible to more people than just the author? It's only impractical if one is playing the role of editor and leaving doc comments on every last typo/grammar error to be resolved and tucked away when they've served their purpose.

Before I forget, just for the sake of sharing it:
https://github.com/Deconstrained/Gummii#gummii-a-web-application-for-writing-and-peer-review

The part of it of which I'm most proud:
https://github.com/Deconstrained/Gummii/blob/master/webroot/js/gummii-core.js
I built some jQuery extensions so that rather than reloading the whole layout, partial content would load in sections of the page. The next thing I'm liable to do is build an endless-scroll thing like on Facebook while making it so that permalinks still work (they'll go to a swath of posts). Heck, it makes me want to go back and work on it just so I can learn awesome new tricks like I did while I was still working on it.
This post was edited by its author on .

!!Applejack 1084

>>1081
I apologize if I seem like I'm making assumptions. Just making the best judgments I can from what I know.

To 1, I understand that. If it's understood -there- where the review community is, individuals and authors will get to where the reviewing resource is, as well as be referred directly from wherever else people get directed to them from. To 2, I'm not sure I get the statement; I mean no offense, it just rambles a bit (as I do myself at times.) We as well, are always looking for new people, and in fact the upward trend here mirrors a downward one elsewhere.

And I simply mean, while there certainly has been too long a time taken for it, I've offered no quarrels or quibbles or contentiousness. I don't see where one could draw that. And I realize imageboards weren't "chosen." But that's how it's come about, and there's been no small amount of growth within them and it has its benefits, not the least of which is how easily people become what's considered a part of a 'community' and a sense thereof.

While it has its drawbacks as well, I think no small part of why someone like Demetrius sees benefit in them (in addition to just the social aspects we've touched on) is that they haven't had the opportunity to see and work with one such as Tinyboard. And of course, I'm fully aware that this move (if we could all just settle on it and offer it the full, good faith work it deserves) is a means of maintaining the /fic/ review community until some indeterminate time in the future when and if some undeniable site/system makes itself known, be it GUMMII or some as of yet unknown thing. The allegiance is to the community, not a URL, something I was aware of from the start. Since that is the case, however, continuing to drag things out with ever further and further speculations and hypothesis instead of, as you said, moving and seeing the benefits and their ability to house /fic/ adequately (and more so than elsewhere) until that indeterminate future, is distinctly the -opposite- of the best thing for it.

I believe you may be seeing the wrong end of social dynamic aspects and the sense of place and community that an actual locale brings, and the cold machinery feel of what's been proposed. Though that's for a future /fic/ to decide, when and if something like those comes about. For now, as said, if you are going with the decision made, let's -actually- go with it, so we can settle and start to work on a) what can be done here to comfortably house /fic/ until such time in the future, and b) be able to have these discussions and speculate and dream up those systems without the limbo these things have the community in. A vast majority was shown, and clear interest (and possibilities) come up with on what can be done here, -and- there's been interesting discussion on some possible future things in docs and such. The future is rather bright, but we're kind of staring at the sun right now instead of enjoying the sunshine. It's kind of keeping things at a standstill.

Anonymous 1140

>>1083
Can I say that is a pretty cool thing you got there? Cause it's a pretty cool thing what you got there.

Now, short points:

On the matter of benefits:
1.) I don't see how it would be any different that the current arrangement where the links to the reviews are posted, and one can click to see them. Plus, three things: Google docs makes it more persistent as it doesn't go down the drain with the thread; most people aren't actively looking into three, two, or even one thread back for old reviews to learn from because they are in so deep; the people who are actually doing the teaching and helping are the individuals of the group rather than the posts in the threads, so making it easier to use and making it more flexible are actually a better bet than trying to close it off so that all activity only occurs within. As a fun note, you can put whole reviews with the formatting mostly intact into a single cell, so you could just send an email which contained the contents of a single cell, which is an alternative to links to other places, having a script making a Google Document to give them that, or the dozen other ways you can store and deliver reviews and requests.

2.) As proven by the recent outages, Anonthony's assumption his dedicated server would fare better than Ponychan's were not only premature, they were completely wrong. He came in insisting that his site was more stable and more secure, and that there would be less downtime. Now that the trolls have set their eyes on it, we can all see this place is as vulnerable as any. The system, if made to exists only within the thread, would be at their mercy and one can only hope that some outage of the server doesn't wipe-out the whole thing. Meanwhile, how likely do you think it is that they can DDoS Google, and remember you can always just send a copy of the whole spreadsheet in Google compatible format to yourself so if they try to take the account down by whatever means you can recover it. Google Apps version just makes it far more secure than this current imageboard base approach.


Oh the matter of socialization within the threads:
1.) I already mentioned the write-offs, and then said how much of the non-reviewing activities occurred elsewhere, and how there was no reason why that reviewing segment occur within the very website. The only thing which the thread could possibly said to do is advertisement, which is the reason most comments were made by Roger's own admission.

2.) The collaborations all died days after they began, with everyone angry that nothing good was coming out of it. There were four attempts, the last one months later because everyone had gotten the opinion that wouldn't work. If collaboration is people angry at each other, well…

a.)I forgot about the other collaborative efforts, like the community threads (of communities which don't interact all that much with /fic/ or anything else), the communal threads (like the story forge and the recommendation threads, both which have waiting times measured in weeks at times), and the every so often feels threads (which haven't existed for months).

3.) It's not mystery that, while allowed, all writers which post threads in /fic/ are told that they will most likely get ignored completely. They are promptly ignored completely. Exceptions exists, but the number is negligible. How can you socialize in a place which are more often than not ignored is a mystery to me.

Basically, I don't buy it, and you just need to go through the /fic/ threads to see why I don't. Socializing has never been a strong point of the environment (the creation of the IRC responded to the need to keep that off the threads and Google Documents, remember?), so I don't see where are you getting this of now.


>>1084
The fact you are still attributing something the community does to an imageboard tells me you don't know squat about /fic/ and you should probably take two steps back and not intervene. Just take a look at your very own website and notice the multiple groups of very close communities which a newcomer has little to no chance of becoming involved.

/fic/ actively tries to get people in due to the people who are in it rather than the environment, and all the benefits you keep describing all end up being things the community does independent of imageboards. Furthermore, I am bother by the fact you actually don't see the fact the community has moved to be an act of full, good faith, because it means you don't understand that the move first failed because they didn't trust you. The fact we are discussing is on a sign we still care about the betterment of the place, and if such better exists elsewhere I don't see why are you bother by said fact. The discussion doesn't hamper your ability to provide for the community, so go do that rather than jutting yourself into a discussion you have no valid voice on due to sheer ignorance.

Finally, locality and sense of community has nothing to do with this matter; I am arguing that trying to bring in the review system into this place is not the best way to go, and I propose a system which would allow quite a lot of the benefits of Google to serve the community and expand its benefits to a whole load of other groups with similar goals. The decision was simply to move, not attach ourselves to MLPchan like a lamprey and hope another place accepts the underlying code should we need to move. I am evading the whole issue by simply keeping the whole reviewing system automatic and isolated, so we can remain here as much as we want without having to worry about that, or you site going down while getting attacked. A /fic/ with an independent engine can act about anywhere it wants, and for now it seems everyone agrees MLPchan fits that better (and I agree, I like it better here). That doesn't mean I buy this full-integration thing you and Demetrius are selling, because I don't see it benefiting anyone in the long-term.

And I'm out.
This post was edited by its author on .

1141

>>1140
One outage out of quarter year versus about once a week does necessary equate to 'less.'

If a day comes some time in the future when full fleshed outside system exist, that should be deliberated then. And if you think it's a good idea, start working on it in the meantime. Just seems confusing to discuss that future while doing something else. And hell, even if there is Demetrius integrated system here, if this doc system you think is so good some day is made, wouldn't people still then move to use it? After all the group made the choice as you say to move once, now they've proved they can accept change for the better. :)

Anonymous 1143

>>1141
The issue is I fear it will end up happening what normally happens here: a sub-par solution is taken, accepted, and then run, all while a better idea is left on the wayside. Once the better idea is put attention to, everything suddenly becomes too much work and you are left with the bad solution for a long period of time, hampering everyone's activities until they adapt to something bad due to being force into it.

The notion there is a choice involve here is deceiving because actions are already underway to carry them out, and I'm not quite sure how many people were consulted about it.

So rather than just keep quiet and hope a better solution eventually comes once they do the subpar one (experience has told us it won't come), I rather make a bit fuzz and show that a much better solution exists, and not pursuing it will only land on in the eternal cycle of "well, it's coming some months into the future, don't worry, I got it."

1145

>>1143
We have already moved well beyond the realm of what "normally" happens. I think precedent is a poor indicator in this context. If you have a good idea you think you can create, do so. That's exactly what's happening now, and you can present it when it is ready. Not doing something else that is good and beneficial in the mean time seems silly .

Anonymous 1146

>>1145
Being anonymous is a poor disguise. Also, I don't want nothing done, I want efforts refocused. I think Gummii is a good lesson of what happens when you try to undertake something complex all on your own, and the Google Apps final strength lies on its ability to exploit the complex in-built abilities. Sure, I could sit down and try to figure all of it on my own, but chances are it won't get too far because complex projects like that don't work well within reasonable time-frames (again, look at gummii).

1147

File: 1353277059162.png (77.17 KB, 200x280, BraceYourselves.png)

>>1146
> I think Gummii is a good lesson of what happens when you try to undertake something complex all on your own
A thousand times this. Now I have a preexisting system and other people to work with.

>>1145
> Not doing something else that is good and beneficial in the mean time seems silly .
Especially since the implementation may end up seeing Tinyboard improved in some other ways, if what I've written is up to par with Macil's standards. It is keeping me up at night and consuming the better part of my weekend because I've found awesome ways that Tinyboard could be made more efficient / elegant. What I've done so far that isn't just eliminating redundant code (but it hasn't been merged into the live site yet):

- Modified posting form template to display "type" field options for creating new thread types. Tested insertion, validation.
- Allowed special citation types (i.e. >>rNNNNN) tested validation/insertion
- Refactored cite insertion such that it inserts all a cite's post in a single SQL statement rather than one by one. Furthermore, for any given post, no matter how many links to a given other post there are, there should be record of only ONE cite to that one post (before it did one SQL query per cite even if they were redundant; now it does some "collection" before a one-fell-swoop)
- Modified post-hover.js so that it can do cross-board hover displays.
- Enabled re-use of duplicate image files rather than accept dupes or reject posts altogether if they contain dupes, to reduce CPU usage / bandwidth / disk space on uploaded images
- Altered file deletion so that it doesn't delete files that are used by other posts, but will if a file isn't used by any other post
- Changed how backlinks are rendered (now it's server-side), to allow cross-thread (and cross-board) universal display of all replies to a post in its header (the way it's currently done is all within the same document, with show-backlinks.js, which isn't very effective
- Changed format of deletion form fields to include URI, so that it's possible to report/delete linked-to posts on different boards (via expanding them and checking the box)

What's next:
- Revamp pagination, to to make large threads more efficient
- Add "thread" and "page" fields to cite so that posts won't have to be pulled up to render cite links (which will point to fragements of a thread, so that asynchronous hover-loading goes faster), but so that they can be taken directly from the cite record

http://www.youtube.com/watch?v=NnP5iDKwuwk


These things are necessary for what I want to do because:
- I want to make it far easier to find responses to a given post
- I want larger threads to be able to operate more efficiently
- I don't want to be driven insane by having to work around Tinyboard as it currently is, but to save myself and other developers effort in the future


>>1140
Can't I try this?

We've done things with an external thing the whole time. I want to see how well an integrated solution will work, plus I want to clean up and improve the parts of Tinyboard that require modification for the new features. I agree with the advantages you mention, but with the exception of how you can't exactly DDoS Google Docs, its other advantages have work-around analogues (i.e. for persistence of data we have archiving and backups).
This post was edited by its author on .

1148

>>1146
Lemme just interject one thing, haha..
>Being anonymous is a poor disguise
Said the anon.
I mean no offense, just playing around.

1149

>>1147
>Can't I try this?
Sure, it doesn't mean that the solution isn't subpar and that /fic/ won't try to make the most of a bad situation—aka, being in an imageboard being the first one, the weaknesses of the spreadsheet coming next, the lack of mods doing anything for /fic/ following closely, and the whole rest of the tango and can-can.

I don't fear /fic/ will be damanged beyond the fact now we have a bunch of smaller groups reviewing in both places; someone will do the reviews. But, again, what truly ends up hurting /fic/ is that we kind of make up solutions as we go along rather than thinking long term. The previous issues of people just don't getting imageboards, the fact !!Spike won't be here to fix every single mistake that will occur, and just a general feeling the Admin wants to get involved in something which clearly has no clue about are just rubbing me the wrongs ways from here to sunday. There is also the fact I fear there won't be enough flow to keep bringing new people, and it all smells to me /fic/ will reorganize itself into a configuration that works, but one that will not actually improve anything.

Let us see how it rolls out, but I can only hope I'm wrong.

>>1148
*shrug*

!SumPony41s 1602

File: 1354076368476.png (27.47 KB, 411x248, Sum_Pony_is_determined.png)

Since the topic has come up yet again in TTG, I thought it would be good to post a progress update. But first:
>>1580
> I am not sure how that would work with Demetrius idea to just keep everything within MLPchan
> everything
A built-in queue for review threads, that's all, really.

And now:
I'm in the third phase of changes. What I've done so far:
- Altered post reply template in service/communal service so that it displays "Add my post to the queue"
- Altered thread-building method of the markup-creation class to populate arrays with posts of different types, for queue
- Altered linkback generation in post headers to use now-imported function for consistency (available in Twig templates): boardLink
- Altered thread template to add collapsible queue boxes (they're a bit bland and could use some styling though)

Still on the to do list:
- Alter post reply template so that on specially-typed posts, it has a link to auto-insert a claim/fill link.

- Modify post functions so that when a special cite is entered:
— Checks the thread type, to see if that type of cite is allowed (also, in the case of the non-communal service thread, checks the post password)
— Checks if the target post is the specific type
— If any check fails, blank out the type field in the cite. Otherwise, change the type of the target post accordingly and enter, and perform any additional tasks.

- Create new mod button for post, "unfill", which (only in Service / Communal Service threads, on posts of the relevant, types):
— Reverts a request to the unfilled/unclaimed request type
— Blanks out the type in the cite that triggered filling it

- Create new mod buttons for posts:
— "unclaim", which (only in Communal Service threads, on posts of the relevant types) reverts a request to the unclaimed request type
— "enqueue", which (only in Service/Communal Service) changes the type of a post to unclaimed/unfilled request.
— "complete", which removes it from the queue entirely by changing its type to "filled request"

- Modify post deletion so that if there are any special citation types in it, the appropriate lookups are taken to revert/undo what the post's cites did (and trolls can't nuke queues / erase their footsteps by posting with loads of cites and then deleting) i.e.:
— If the post type is filled request, and the request has no other filling cites, unfill the request
— If the post type is claimed, unclaim it
This post was edited by its author on .

Demetrius!WDFBcC5x22 1729

File: 1354456344241.png (159.29 KB, 777x688, Screenshot - 12022012 - 05:48:…)

Success.

I got the basic citation & state change system working (basically all the queue system). What remains to be done is setting it up so it handles post deletion well (resetting queue item states), and adding some moderator buttons for interfacing with the system in case people make mistakes or try to abuse it. I'll also be doing a lot more testing. Hopefully soon I get done polishing it, we can work on getting this stuff implemented live.

In standard service threads
Only the thread owner (identified by password) can fill requests, and only within that thread. There's no "claiming"; requests are implicitly claimed by the thread owner.

In communal service threads
Anyone can claim/fill, and can do so from anywhere within the same board (so someone could claim, and then review it off in their own review thread, and the change would be visible).

In both types
"Feedback" (to make a filled request disappear) can only be given by the original requester. One can claim (or simply cite), then go back and edit the claim post, change the "c" to "r" in the cite (or add an "r" to begin with) and then paste in a review, and submit the edited post, and the post turns into a review (updating the queue in the thread as well).

I tried making a screencast of me testing it, but my screen is 1080p and transcoding was taking a hell of a long time, and I got impatient. Pics or it didn't happen? I have pic. Now I need sleep.
This post was edited by its author on .

1730

File: 1354456758928.jpg (80.8 KB, 500x353, banzai.jpg)

>>1729
First off, you are a wizard.

>"Feedback" (to make a filled request disappear) can only be given by the original requester

So that would mean that the requester must make an acknowledgement post, then, or the request does not clear from the queue?

Demetrius!WDFBcC5x22 1733

File: 1354458992134.png (125.95 KB, 1000x802, Screenshot - 12022012 - 06:35:…)

>>1730
Correct. That, or it can be reported for clearing, and then a mod would hit a button in the post header to clear it (still on my to-do list).

1739

File: 1354469302549.jpg (26.62 KB, 393x296, Spike - wizard.jpg)

>>1730
>>1733
>>1729
Rest, mighty wizard.

2222

File: 1355040442937.gif (821.64 KB, 585x537, zecora-meditate.gif)

I didn't think this was worth bumping the thread for, but I did think it was worth an update.

I'm working on getting the thing to handle post deletion properly. I've gotten it pretty much all done except for a bug that was introduced in my previous changes that makes it so that links aren't removed properly during post-rebuilds that are triggered by deletions. So, it's a little more bugfixing and testing, and then on to the moderator buttons.

Edit: yay, figured it out. More testing and stuff tomorrow.

Also, how do these use cases sound?
- If a claiming post is deleted, the claimed request item (if it's in the "claimed" stage) becomes unclaimed, unless there are other claims on it
- If a post filling a request gets deleted, the filled request (if it's in the "filled" stage, not the after-feedback stage) reverts to unclaimed request, and all claim-type cites are "blanked" (meaning, they turn into ordinary cites) unless there are other posts that fill the request
- Any other scenario: no change in the type/state/stage of posts
This post was edited by its author on .

2270

File: 1355125906640.png (17.82 KB, 465x375, Screenshot - 12092012 - 11:41:…)

Yay, all done!
This post was edited by its author on .

!SumPony41s 3954

File: 1360387577768.png (38.94 KB, 200x200, Sum_Pony_shrug.png)

So here I am on a Friday night, absentmindedly composing a drunkpost about nothing using my pretentious tripcode – pretentious in that it is a mere echo of what I once was If the threads in /site/ are anything to go by, it's pretty obvious at this point that Macil is preoccupied with making this board more secure and stable. Considering that, and how much time has passed, and how my commits were made in big messy chunks (thus making them even harder to merge), there's not a snowball's chance in hell my branch will ever get merged.

Rather than bitching about how I wish I could have my November 2012 weekends back, I'd like to ask: do you think it would be useful to have an ultra-simple, dedicated website for reviewing, where reviewers are people with registered accounts, and people who request reviews can drop off without registration (but captchas and whatnot else)? I've been exploring this in my mind (and keyboard; I've made an ec2 vm for it and have been doing some stripping-down and unit testing of Gummii), but wondering about the utility of such an effort. It would be like The Training Grounds, only each reviewer has their own "personal queue" that reviewees could request/submit to, and unclaimed requests or requests made to no one in particular would go in a public queue until someone claims them.
This post was edited by its author on .

3955

File: 1360388403193.png (535.42 KB, 956x1024, my brain is full of cupcakes.p…)

>>3954
On the one hand, I love the idea of a "review central".
On the other, a review board is only as good as the traffic it generates and the community it supports.
I'm torn, bro.

Cupcake?

!SumPony41s 3957

File: 1360388887893.png (24.23 KB, 295x374, Sum_Pony_is_commutative.png)

>>3955
I totally agree. That's why I ask if it would be worthwhile; there are other things I could be spending time on, and it seems I'd be developing a standalone reviewing app for a dramatically shrunken userbase at this point in time. If I had a magic basement I could disappear into, where time moves more slowly and I could focus on coding and forget about rent and work for years (this is after all a subterranean Narnia in momma's house) I would have had this baby up and running months ago when it could have reached critical mass instead of, like, back in the formaldehyde after a shock to the brain in attempt to resurrect it after taking it out of the formaldehyde after aborting it.

I'm not sad, just a bit disappointed. Oh well. Time to practice a few chords, eat some popcorn and write the rest of a chapter of my little story.

Oh, and by the way, it is very good to see you around again, old friend.
This post was edited by its author on .

Anonymous 3958

>>3957
Could someone explain to me why not integrate it directly into Fimfiction? Hell, make ponyfanfiction archive look less like shit, add this as an integrated feature, and you might be unto something.

All I'm saying is that having a secret hide-out for the reviewers is only cool is you want everyone to not actually come.

!SumPony41s 3959

>>3958
Knighty is "hesitant to reveal site code" according to someone I'm in contact with (who's working on a standalone app that interfaces with FimFiction). Also, unless it's based on some trusted development framework and not written from scratch (hell, doesn't have to be one I'm familiar with; could be CodeIgniter or Pylons or even RoR for all I care, just as long as it's well-documented) then no. I'm not about to dive into an investigative study of how someone else's rat's nest of ad-hoc code works. It will profit me nothing, as I've already learned from writing code for Tinyboard (well, to be fair, I learned how to use the Twig templating language).
This post was edited by its author on .

Anonymous 3961

>>3959
Then ponyfanfiction archive de-crapification seems the only option, seeing how their source is apparently available and might fit into your demands. Beyond that, at this point a place only to get reviews for only pony fanfiction wouldn't do much beyond wallow in abeyance as people ask themselves why bother with an extra step.

3970

>>3959

Funnily enough, Kazune and I are working up initial planning for a site that functions both as you've stated and for a few other things writing-related.

Anonymous 3979

>>3970
Is there any actual programming brunt involve, or is this just a "when I have nothing better to do" project the place is so fond off.

3980

>>3979

If by "when I have nothing better to do" you mean "all the time," then yes. There's actual programming brunt involved.

3982

>>3970
Seeing as the most popular fanfiction sites are either based on a crappy old CMS whose own wiki is broken* or 100% undocumented, top-secret ad-hoc code that only one person is allowed to see/touch and develop extensions to, I'd be all over a more open fanfic site development project. The problem, as others have pointed out, is "why bother" (with another fanfiction site). Still though, I'm curious as to your strategy for development.

Also, for the record–
>>3958
> All I'm saying is that having a secret hide-out for the reviewers is only cool is you want everyone to not actually come.
My idea wasn't a "hide-out", but more of a service depot where users from FimFiction and elsewhere could toss their stories. Again, like a fusion of review threads and TTG.

* PFA: http://www.efiction.org/
Parse error: syntax error, unexpected T_NAMESPACE, expecting T_STRING in /home/timet4/public_html/efiction/wiki/includes/Namespace.php on line 49
This post was edited by its author on .

Anonymous 3986

>>3982
I think the problem is less of "yet another fanfiction website" and more "yet another superniche website which doesn't make sense to be its own separate thing".

Also, are you the same guy who was making the logo, figments? I bring it up for good reasons. Mostly an attention call to be realistic.

And, finally, I was being facetious. Of course it isn't hidden, but if this place didn't tell you, a separate place from where you normally work is the easiest way for you to never even hearing about it.

3987

>>3986

Not to be pretentious, and I might receive flak for this, but…

>Reality is whatever refuses to go away when I stop believing in it. - Paul K. Dick


Seeing as a bad habit can be changed with a little bit of applied will, realistically speaking - implying that I'll never change is wrong.

Realistically? I won't make it. I'll flop out and eventually find something else to bide my time until something else pops up.

But Kazune's an ass. And he's pretty good at kicking mine.

Besides, a little friendly coercion never hurt a fly. It might even make this old habit die hard.

And no. That wasn't a movie reference.
This post was edited by its author on .

Demetrius!WDFBcC5x22 6611

Just thought I'd like to comment that most if not all the stuff the anon suggested earlier is possible now using the "query" and "importrange" functions. Ah well. But damn, technology moves.

Anonymous 6628

>>6611
Whatever the hell happen to… well, everything?

6694

File: 1373173055504.jpg (323.21 KB, 2779x1850, yifRp.jpg)

>>6628
Never mind; forget I exist :-P

I'll spare you the details but sum it up by saying life now is a Mandelbrot set's edge of "holy shit I have to finish X before Y." So, don't expect anything of me.

What I meant to say is that you can import data from other spreadsheets using *native* Google spreadsheet functions, which makes the anon's idea totally feasible. I never meant to suggest it should/will be done, just that it could be done, as a "for the record" footnote to this thread.
This post was edited by its author on .


Delete Post [ ]
Edit Post
[ home ] [ site / arch ] [ pony / oat / anon ] [ rp / art ]