What solutions are there for "meta-discussion"?

Question

UPDATE: Q2A now supports this natively, see this question.

---

It's clear from a few months of using Q2A that I could do with a way to section meta-discussion - i.e. questions about the site itself (for me this would include my main site and the Q2A section).

Does anyone have any ideas for how to organise this?

Interestingly, my "ideal solution" that I came up with several weeks ago is pretty much what Stack Exchange is now doing with their new sites: Meta is a subsection of the main site, where the users are automatically inherited from the parents. And no-one gets any points from meta.

Would this be possible with Q2A by doing the following?
- Setting up a separate Q2A instance.
- Use Q2A's "single sign on" to let users log in with their account from the main site.
- Hide all mention of points on the meta site.


Another possibility would be to have a special tag like "meta" that users should add when asking about the site. Questions with that tag would be hidden from the main page but accessed from a special page.

Any other solutions?

Answer 1

I think your suggested solution is a good one. It should be fairly easy to set up one Q2A instance to use single sign-on based on another.

As an experiment, you might even want to try using a MySQL VIEW or MERGE table to share the users and userprofile tables between the two installations. In other words, if your main Q2A site uses the table prefix qa_ and the meta uses qa_meta_, you would set MySQL up to treat any query on qa_meta_users as a query on qa_users, and likewise for qa_userprofile and qa_meta_userprofile.

To be honest, this may or may not work, but if it does, it's easier than writing the single sign-on code!

Comments

Since I'm not sure how foreign key constraints would work with a VIEW table, I suggest just removing any such constraints that are causing you problems. They're only there for consistency checking anyway.

http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html

---

Thanks, removing all use userid constraints worked. (Actually, they were all pointing at "qameta_users1" which is what I renamed the old table to.) But everything seems to be working now :)

---

Sorry for noobines, but what is 'MySQL VIEW', mysql section or what ?

---

@FriendlyOne: It is a special type of table that is essentially taken from any MySQL select query. You could create a view that is a join on multiple tables. But in the case above it's just a replica of the qa_users table, but named qameta_users. (You can create views in phpMyAdmin easily, or Google for the query syntax.)

Anyway so now the meta site selects data from qameta_users, and behind the scenes MySQL returns data from the qa_users table instead.