A road map to "public beta"

Question

In the context of these discussions, the majority of us rather agreed that it is a good idea to go publicely online as soon as possible, even if this means that we focus on the Q&A section first while keep developping the (hidden) Reviews part of PhysicsOverflow.

So lets get serious about that now :-)

As this thread was written, we assumed that the Reviews and Q&A sections will be brought online at the same time, before we realized that developping the Reviews section is slightly more involved than thought at a first glance, so it still contains many issues that can actually savely be solved while the site is already publicely online.

So lets make a new list of things that urgently and seriously need to be done before going publicly online with the Q&A part of PhysicsOverflow ("Public Beta"), because if not resolved they would strongly  handicap the functionality of the site, make us look unprofessional / diletante / or otherwise bad, etc ...

Making this final todo list should be rather straight forward, as we need mostly to take out and copy here the relevant unresolve issues already listed here, here, here, and here for example.

So when everything in the emerging (and hopefully not eternally inflating) todo list is [DONE], [RESOLVED], or [DEFERRED], PhysicsOverflow should finally get born !

Note that certain things (such as adjusting the permissions in the Admin Panel, moving the URL to our final home, etc) should and can be done only a short time before the big bang PhysicsOverflow will hopefully make in the physics online community :-) ...

Comments

I have installed the Permission2Categories plugin of Kirill Fuchs. Actally, all categories are set as visible and accessible to all. Before we go online, these permissions will have to be changed. When you edit a category in the admin section you will notice a select box. Simply choose the permission level you would like to set.

Note that P2C treats sub-categories as a normal category, it does not take it's parent category permission level into account. So we will have to change permissions for all sub-categories.

---

OK, I see you want to have me out there ):-P
Let me see what I can do.

Edited: Uuups, anonymous that was polarkernel.

---

I have adapted the Permission2Categories plugin of Kirill Fuchs so that it allows now also creating permissions based on user rep.

When you edit a category in the admin section you will notice a select box for the user level and another for the required rep. Both are combined using an OR. If for instance the user level is set to Expert+ and the rep level to 500, a registered user will see the category if he has more than 500 points, while an expert will see that category, even if he has zero rep.

The category permissions will only be set if you click "Save" in the category edit section. It is only required to set the permissions on the restricted categories; all other categories will not be affected. However, sub-categories are treated as normal categories; they do not take their parent category permission into account. So we will have to change permissions for all sub-categories of a restricted category. Actually I have not yet set any restrictions. @dimension10 Do you like to set them?

---

@polarkernel Thanks a lot : ) I will set the permissions for the community moderation category now. 

I am not sure if we need to actually make the reviews section hidden, it won't have any posts for now anyway. 

---

@dimension10 Wait with the review section until we have defined the category system for this section. If the depth of the categories will be large, I will add a checkbox to this plugin that allows to set the permissions automatically to all sub-categories.

---

The plugin enables category permissions based on the user level (Anyone+, Expert+, Editor+, Moderator+, Admin+ and SuperAdmin), but not on points. Would in this case a point based permission be required?

---

If we want to make community moderation (the section) only visible to > 500 rep users, the point based permission is required ...

Answer 1

Users with long usernames such as "WetSavannahAnimal aka Rod Vance" and "Eduardo Guerras Valera" need to be handled separately because the same bug that affected "Dilaton (SE User" is affecting them too. "user10001 (SE User"'s posts also need to be re-imported.   

Comments

@Dilaton I have removed the [DONE] because it is not actually done. I am yet to correct the post owners to the real ones.  

Answer 2

[DONE] 

The navigation bar has to be de-cluttered. 

Comments

Yes, this would be nice if it can be done relatively easily, otherwise the navigation bar is functional enough to start with in my opinion.

---

@Dilaton It should be. Even at a worst-case-scenario, it can be done quite easily through jQuery. Unfortunately, for some reason, it is not possible to add jquery through the admin panel it seems, the same has happened for previous such attempts of mine.  

Answer 3

[DONE]

Are the upvote and downvote buttons too near to each other?   

Comments

Yes, to me they seem to be too near each other, in particular when typing on a smart phone ...

But as conversely to many websites, votes are retractable here, this seems to be not a crucial handicap for the bublic beta

---

@Dilaton The problem is, it may not be immediately obvious for some, especially if they have hyperopia, that they have accidentally given the wrong vote. This is dangerous on Q&A.  

---

So maybe it would help to explicitely state it in the FAQ, and if needed even stronger measures auch as explaining it in the mail to newly registered users, could be taken ...

But if I understand this correctly, it rather involves  a change in the theme than a core hack (?) so maybe it is not that complicated...

---

Is it better now?

---

Yes it looks good now... :-)

But your comment did still not trigger the message box  ... :-/. If I remember this correctly, replies to ones posts and comments as well as upvotes for example triggered the appearance of the yellow dot.

---

Yes, it's much better. 

Answer 4

[LATER]  

The simplification of the editor must begin.    

Comments

I am not sure how crucial this is for the public beta, as the editor at least works bug free as is. So if it should become a too narrow bottleneck on our road to bublic beta, I think it could be safely [deferred] if needed.

---

@Dilaton I have added "[LATER]", but I remember polarkernel said this is freely configurable, and even if it was not, it can be removed through CSS anyway. 

Answer 5

[LATER] 

The logo needs to be polished. The design idea looks great compared to what we started with, but needs to be updated so it's more professional looking.

Comments

Could you give a more concrete suggestion? This is not so urgent for the public beta. We can have people suggesting logos after the site is running, too. 

---

@dimension10 could you also make the line parallel to the upper sans on the h? Then your modification can be posted on the main logo thread to make sure everyone else is OK with it.

---

@physicsnewbie Done, are you fine with the new logo? 

---

@physicsnewbie As for the font of verflow, Helvetica looks terrible. Do you have any idea for a "flow"ish font? What about this? 

---

@dimension10 looks great!

---

@Nope, I disagree on simplifying it any further. The verflow is blue to give it a "flow" and the "O" gives a nice "black hole" idea on the "physics" side and a  "hurricane" feel on the overflow "side". If you ask me, the LaTeX feel is very accurate. Capitalising makes it look unprofessional and "shouting", like on Physics.SE (or Maths.SE). The LaTeX feel does work here.  

---

@dimension10 what do you think of the mathoverflow font?

Answer 6

[LATER] 

Manual input for review section needs to be up and running. The bot downloading from Arxiv isn't urgent and can be added later while the site is public running.

Edit: From the discussion in the comments, I agree that we might as well implement the bot first, since most of the reviews are going to be from Arxiv anyway.

Comments

Aargh! We will be hiding the reviews section in the public beta! Did you not read the question? I think, if I am not wrong, that the main difficulty is having two voting criteria, and not the importing. 

---

And the bot downloading is more urgent than the manual input plugin. 

---

@dimension10 If the review section is going to be hidden for the Beta because it's not ready, then that's OK. But I'd say the manual input rather than bot-download for the Review section is more urgent because people are more likely to review and comment on a review someone has brought to the attention of the community.

---

The urgent thing is to figure out how to implement the reviews inside the code for Q2A without major modifications. I have studied the code to the point that I have some understanding of it, and there is a built-in mechanism of adding plugins and function-overrides which can allow you to implement what looks like a pretty general extension without forking, as a plug-in. I will look to see if this can be done for the reviews.

The reviews simply can't go up until there is a good mechanism for ensuring fair and accurate ratings. If you put up a half-baked thing, it will reflect badly on the site. The ratings have to be serious right off the bat, comparable to the refereeing of a good journal.

---

@physicsnewbie I completely agree with what Ron is saying here.

I can't help but think that your (physicsnewbie's) comment is meaningless. How should users review when the reviews section is hidden to them?!

Also, many users will rather review ArXiV papers (not judging if this is right or wrong) than manually important papers because there is the assurance that "this paper was accepted on the ArXiV", whereas one can import completely unreviewed papers (this is NOT a problem). In other words, people will automatically think that there is a lesser chance of there being crap on the ArXiV than on some random site.    

---

I agree with Ron. Until we have defined and implemented the new question type incorporating the proposed rating, it is not possible to import papers, neither by bot nor manually. This is the first requirement to be achieved. It makes no sense to import papers until we know how they have to be imported.

The envisaged question type is completely different to standard questions and most of the time to get review working will be spent for the development and incorporation into Q2A for this new question type. Additionally, there are still a lot of open questions about the definition of the review questions itself, like

• What shall the username be? (Q2A provides only one tag in the posts record).
• How shall the authors be registered in PO?
• How to distribute the rep to the authors?
• How making Q2A to sort the review questions (done by novelty, vote count, answer count, view count for standard questions)?
• Who shall be able to edit these questions?
• ...

Creating a plugin, that allows manual import, will take an afternoon and the import of ArXiV papers maybe some days. This is really not complicated. But it requires the existence of the new question type. Every other way will be a hack and look like a hack.

---

@dimension10 AAAARRRRGGGGHHHH! Isn't it obvious? When the manual input is working, then the Review section can be made public. On the other hand, I now agree that it would be better to implement the bot first, since people are more likely to review Arxiv papers. That's assuming there isn't much difference in time between coding a bot and a manual input.

---

Hi Polarkernel. I studied at the Q2A code pretty intensely this weekend, learning PHP was much easier than I thought it would be (I'm familiar with Perl), and learning javascript was both trivial and pointless, as there is nothing required client side.

I think the plugin system might be general enough to implement the section, but I also fear that it will require a new database structure specifically tailored for the review. I also had ideas for a recursive point system which is rather involved, and requires frequent traversals of a tree structure. This can be done, but it might be good to implement in a different kind of database structure, which is more friendly to recursive traversals (I don't know databases well enough to know how easily they can accomodate traversals that hit thousands of nodes again and again).

I am sure that I can do something here, and relieve your burden regarding programming, but I am not sure what the database requirements are--- do you need to have only one database for all the questions? Or can you have two databases in the code? Can you use files and independent C code on the server instead of a database? What are the freedoms you have on the hosting? How many gigs of storage? If you would like to send me an email, feel free.

If you can make a plugin with its own database to deal with reviews, then it might be possible to make a complete plugin that does the whole job, from scratch. but I am looking at the code at the moment with an eye to do minimal extensions which are optional, which are general enough to allow a review section.

To this end, it would help if you could tell me from your experience what kind of things you can do with plugins. I looked over the plugin code, and it seems to have a function replacement thingamabob operating independently, which can substitute user-defined functions for a whole bunch of standard PHP functions. But I didn't see how wide the scope of this system was.

---

@Ron Maimon First of all thank you that you want to help me!

I answer your questions here because other users might also be interested in some technical details. Q2A does indeed provide a bundle of useful interfaces like plugins, pages, modules, layers and advanced themes, which allow changing the behavior of the site. To use them was my preferred way to implement the requirements that came up on this site. We should continue like that, because if Gideon Greenspan (the main developer of Q2A) releases a new version, he will take his freedom to change whatever he wants in the core code of Q2A, but he will not change the interfaces of plugins and the other modules, because too many of them already exist.

The logical design of Q2A consists (main parts only) of users and posts and a main engine (the core of Q2A) which prepares the html pages, processes clicks, inserts the data into the different tables in the database (actually 37 tables). This is a huge task and we have not to care about. We normally change just details, but in principle, we could catch events in a plugin, or better a module, and capture the whole system into our code. There is no limit. If we wanted to create a new type of question, with a new rep system (many instead of one user), with a completely different tag system, with a different design of the page and with its own database tables, we would also have to rewrite a large part of the main engine. This would absolutely be possible, but in this case, we could really make it working in August, but August 2015. So my goal is to put as much as possible into the existing code. And I am fairly sure that this is possible in a reasonable time.

Creating and using new tables in the database is quite easy from PHP. We have actually only one database available, but it can be expanded with no problems. In any case we will have to do that for the review section, because we want to store data types that do not yet exist in the original tables. I know how to do that and am already experienced.

To the features of our host: We have one database as I already mentioned. Actually there are 5 GBytes of storage reserved, but it can be expanded in steps up to 2 TBytes by one mouse click, it just costs more. Today we have used 50 Mbytes (1%) of this storage, so that will be no issue for a long time. The PHP engine is given; we may not change it (and therefore not call C or C++ code from there). The database is a MySQL engine. We have unlimited traffic available. I selected our host by the requirements I knew on the start of this project (a simple Q&A site), but if it should be too weak once, there would be (almost) no problem to move to another host.

Writing PHP code is extremely simple. Some experience with object oriented programming is enough. However, writing code for client-server interactions (the interactions between the server and the browsers of the users) is much more difficult. There exists no really valuable debugger. Sometimes, the only way to follow the process is to user var_dump() and die(). This makes it difficult to find bugs, even more if the code is not or only poorly documented. Additionally, there may be interferences between the plugins and/or the javascript code, that are very difficult to find (I assume that the actual bug in the message box has some reason like that).

OK, now how can you help me best. Most important to me is to provide a precise and detailed list of requirements you like to have in the review section. What I have found in all the posts is still quite cloudy and ambiguous to me. If you like to define parts of these or your additional ides already in PHP, even better. Once I know exactly what you want to have, I will be quite fast to implement it. Discuss your ideas with me (maybe better by email so that we do not bother the community with that) and together we will be fast and get this exiting site running completely before August.