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:
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
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 .