User talk:Chughakshay16/ConventionExtension

Please feel free to add any suggestions on this page.

Previous page history was archived for backup purposes at User talk:Chughakshay16/ConventionExtension/LQT Archive 1 on 2015-07-10.

Because we need to make sure that we don't require everything to have admin rights. :)

In terms of user roles/privileges, I am often an admin (Sysop or Bureaucrat) on the wikis for the projects I am organizing conferences for, or I know people who are and are willing to do some setup on my behalf.

This means the privileges of a Sysop are accessible, but it would be good to only need to use them once or twice for setup (perhaps the suggested workflow is to create a namespace for a conference and give the conference organizers admin access only to that namespace?) Generally speaking, "normal users" on a wiki should be able to be conference administrators, I think, since the ability to organize an event is orthogonal to the ability to moderate a wiki, and because some people come in specifically to volunteer for the conference.

I am usually not the sysadmin. Conference organizers usually do not have system administration knowledge (I'm a bit of an exception) so it's going to be important to have installation/setup instructions that they can just point their sysadmin to. The instructions should tell the conference organizers what information they need to give the sysadmin (name of conference, usernames of people who should be able to admin it, etc). so there's not a lot of need for back-and-forth emails.

This post was posted by Mchua~mediawikiwiki, but signed as Mchua.

Hello Mel,
I see what you are trying to point out by saying that an admin shouldnt have the sole responsibility of administering a conference, well for my extension I would be distributing an important set of editing rights for organizers as well. As you can see on this page that an admin gets to choose the group of people which can be assigned as organizers for the conference, hence meaning that organizers would get to do almost everything that a sysop(admin) could do on a conference (this includes editing rights for all the conference pages).
And speaking of if volunteers should be given rights so that they could make changes , I say that we could create more groups with customized set of permissions and later let admin assign any volunteer to be part of any of those groups.

Akshay -- I just got your email, so here are some thoughts I have on the current design and features I'd like to make sure are considered (things that are important from an organizers's point of view, but may be easy for others to miss).

• Allow attendees and speakers to edit the information they have submitted (for instance, if they decide to change their affiliation, or the title of their talk, they should be able to do that).
• Sometimes, conferences have more than one venue (for instance, we might be hosted by a university and be using classrooms in two buildings, plus the cafeteria). I think the ability to use different locations, and to link to pages that have more information about the location (such as addresses and transit directions) would take care of this.
• Sometimes, events don't fit into regular timeslots. For instance, a conference may have talks running every hour (1pm, 2pm, 3pm, etc) but also have a poster session that runs for 2 hours (1pm-3pm) and lunch beginning midway through a session (1:30pm) -- so we need to be able to customize times for each event.
• Allowing attendees to register even if they do not have an account on the wiki is a good option to have, because sometimes events are trying to recruit people who are not Mediawiki-savvy. In Fedora, we do this by creating a special namespace for events that is editable by non-users (you need a login to edit the rest of the wiki). You can see the registration for one of our events here: http://fedoraproject.org/wiki/Archive:FUDCon:Toronto_2009#Pre-registration
• Think about the process of selecting talks and generating a conference schedule. You have a lot of talk submissions, and you need to (1) pick the best ones, and (2) assign them to time-slots in different rooms. This is often done by a group of people (who may be working distributedly). So this is one scenario to make sure the extension handles.
• It would be wonderful to have a schedule generator -- after the conference organizers decide which talks will be at which times in which rooms, they should be able to tag the "successful" talks with their time/location, and then there should be a page that pulls that data and creates a schedule grid (such as http://fedoraproject.org/wiki/FUDCon:Toronto_2009_BarCamp_Schedule). Perhaps that page would automatically pull in some other information too (like directions to the location, or a short introduction or message-to-attendees for the conference) so attendees could just print that page and use it for reference.
• You might notice that each entry in the schedule grid above has a log linked to it -- it's important to be able to link back to more information about the talk (abstract, materials people need to participate in an activity, etc) and to be able to put in notes and minutes afterwards.

Hope this helps; I'm happy to test/draft/comment more specifically on particular features/ideas/workflows if you like, you know where to find me now. :)

This post was posted by Mchua~mediawikiwiki, but signed as Mchua.

There are many things related to the conference, which sometimes are done by different tools:

1. Attendee registration (payments, pre-paid attendees, scholarships)
2. Handling of accommodation issues (price, rooms, who shares with whom, multiple accommodation sites)
3. Program - submissions, review etc. This is can be handled by software like EasyChair or Pentabarf. The output should be ready to use program (but then you need rooms, timeslot management, etc.)
4. Wikimania has also scholarships - there is an application form and review process by the committee

I have looked into the issues that you pointed out :-
Here are some of the things that that might help me solve some of the above issues
1. database changes for features such as scholarships(and a special page for a scholarship applicant)
2. submission form for the speakers .
I still havent quite got hold of the idea of how to handle accommodation issues. And as I already pointed out earlier , paypal generates a 'Buy Now' button for you so that can be easily integrated into our extension code.(but admin needs to have an account with paypal)
Please correct me if I am still missing something.

1. Current code used in 2012 for scholarships: https://github.com/saper/Scholarships
2. Sumissions could be added to a wiki using this page, which used this submission template. You can have a look at all submissions here: wm2012:Category:Wikimania_submissions.

I don't see how are you going to approach this so it's hard to tell what is still missing.

Hope this helps.

For Fedora events, we use a Trac instance to handle scholarship/funding requests (each request becomes a ticket, and the admins can accept/deny it and track its progress from "reviewed" to "approved" and "paid" or "reimbursed"). It works really well, and it might be an option to try and find a way to integrate Trac (or some other ticket tracker) with Mediawiki for events (this probably means finding an existing plugin, and tweaking it for events-specific cases), rather than trying to reimplement all the functionality in the wiki code itself.

https://fedorahosted.org/fudcon-planning/ is the Trac we use.

This post was posted by Mchua~mediawikiwiki, but signed as Mchua.

Hi Akshay! I'm spending some of my extra time working on improvements to the HTMLForm classes in MediaWiki core. I don't know if you have experience with HTMLForm, but it's a pretty cool MW feature that makes it easy to construct MW-friendly and secure web forms. However, it's limited in what it can do and how it outputs forms. Right now, it only outputs forms wrapped in a table and table elements, which is kind of a pain in the butt and IMHO, not very usable. So one of my main goals is to make it so HTMLForm will output forms in a variety of possible formats: table, wrapped in divs, or just raw form elements. I imagine you'll be looking at using HTMLForm for your GSoC project, and just wanted to touch base with you and see what you think, let you know that I'm working on this, and see if there's any space for us to collaborate a bit. I hope all's going well - congrats again on being selected for GSoC :D

Its really nice of you to come and discuss this with me. And it really seems like something that I would be happy to collaborate in. Although at this point I havent made much use of HTMLForm class in any of my work, but as you point out I could really use it while implementing UI interfaces for my project. As you may have seen in my project schedule that I am not gonna be working on building UI interfaces before the 2nd of June, so I would suggest if we could start to work on this feature before May 21st and later on resume after 2nd of June . Well you could always send me an email at chughakshay16@gmail.com or just post it here for discussing any of the details regarding this feature. Looking forward to work with you. :)

The ranking procedure can be applied for proposals, and scholarship applications.The idea is really simple :
First the admin assigns reviewers for the conference(Only these people will have the right to rank proposals).
Secondly , each reviewer will rank a proposal on the basis of different criteria. For example, in case of scholarship applications the criterion would be :-

• 'nationality' ,
• 'validity'(meaning if the proposal is valid for even being considered),
• 'onpresence' (the contribution towards the project hosting this conference),
• 'outpresence' (the contribution towards projects other than this one),
• 'future' (commitments to be fulfilled in future by this applicant),
• 'representation'(which firm or company the applicant represents)

Similarly criteria like 'affiliation', 'content','idea' can be applied for the proposals submitted by speakers. Changes in Data Storage :-

• 1. Ranking page(wiki page)

content : criterion | rank | time
page_props :

+-----------------------+---------------------+----------------+
| pp_page               | pp_propname         | pp_value       | 
+-----------------------+---------------------+----------------+
| ranking_id            | application_reviewer| reviewer_id    | 
| tr_reg_id             | application         | application_id |    
+-----------------------+---------------------+----------------+

• 2. Reviewer page(wiki page)

content : empty
page_props :

+-----------------------+---------------------+----------------+
| pp_page               | pp_propname         | pp_value       | 
+-----------------------+---------------------+----------------+
| reviewer_id           | reviewer-user       | user_id        | 
| reviewer_id           | reviewer-conf       | conference_id  |    
+-----------------------+---------------------+----------------+

So above changes imply that per application per reviewer one or more than one ranking pages can exist.