RFC: Should we implement everything as a Wiki?

[sumnerevans]

We are in the process of trying to integrate Project pages (#40) and User profile pages (#39) into the website. Each of these will have a large amount of dynamic data.

For example, all projects have a title, description, project leaders, etc., but they may have any number of other fields that are specific to the project.

Also with Users, most people will have a name, bio, some contact information, etc., but they may have any number of other fields that are unique to them.

Because of the amount of dynamic content on these pages, they sound wiki-ish. I'm laying out the pros and cons for implementing these as Wiki pages, or individually.

Wiki

Pros

• it's easy for a project/user to be able to add arbitrary data to the project
• we won't have to clutter up the User and Project tables with random, likely sparsely populated, columns.

Cons

• it will be difficult to enforce consistency across user profile pages and project listing pages
• we will need some way of linking from the project listings (see Project Listing Page #35) to the project page, and keeping the data up-to-date
• we will need some way of associating a user with a wiki page

Individually

Pros

• visual consistency will be ensured across user profile and project listing pages
• linking projects and users to their respective data will be easy

Cons

• we will have to add a new field to the User or Project tables in the database whenever we want a new field (for example, maybe in the future people want to include their Twitter handle on their profile)
• even with the current designs, we will be adding a bunch of fields to the User and Project tables

Possible Compromises

1. Limit the number of options that can be added to a User/Project and then allow them to link to a Wiki page with further information.
2. Include some way to embed a wiki page into the project page.

These, too have their pros and cons.

[jackrosenthal]

Let's not do everything in the Wiki. Only things that are textual/documentation style. For example, profile fields should not be implemented in Wiki, but I would not be opposed to things like a bio being implemented in the Wiki.

Why not we consider something MediaWiki style. For example, if a user wants custom bio etc. to appear on their page, they can create the wiki page User:Username where Username is their username, and that would "link" it to their profile. We could even add easy buttons from the profile page to create this page. And current wiki system deals with permissions, so User:*** can simply have special permissions.

Same for Project:***.

And if we implement subpages (which was the plan I had for wiki), subpages of that User or Project page can automatically be linked as well.

[jackrosenthal]

we will have to add a new field to the User or Project tables in the database whenever we want a new field (for example, maybe in the future people want to include their Twitter handle on their profile)

Don't think of adding extra columns as a bad thing; it's rather a good thing as it provides migrational consistency when we make changes. For example, suppose that a social provider buys another, and accounts are merged. Handling this with a migrational change would be easy, but hard with a mess of Wiki data.

[jackrosenthal]

As an added note, don't look at current Wiki code. It's a severe f**k up that I need to fix.

[sumnerevans]

Ok. That sounds good. We will proceed with adding columns as necessary to the database tables, keeping in mind some things (such as a bio) might be migrated to a wiki later on.

Once wikis are implemented, and we have a better idea of use cases, we can revisit this and determine what, if anything, should be migrated.