Long term developments

[Derek Lande]

Hi Guys,

While I am neither mathematical nor technical enough to weigh in on the current discussions I am interested in helping out with the project.  I am thinking of trying to get together a wish list of features so that we have some idea what we'd like to see in this software in the future.  Some are little things... some are pretty big and may involve big rewrites etc...  In particular I have ideas in relation to judge allocation.  Some may be impossible/just too much work, but I think there is no harm in brainstorming a little.

Do you have any system in place for managing feature requests?

Well done on the work so far.

Derek

[Klaas van Schelven]

Hi Derek, others,

Much appreciated! I'm looking forward to your ideas. Also, someone who would be willing to keep more of an eye on features than just do whatever seems to be urgent / fun could be very useful. Also, if you can find programmers in your personal environment and create some enthusiasm for working on Tabbie, that would be very nice.... (in fact, this goes out to all readers).

I've tried to set up something more sophisticated in the past (wiki's etc) but I guess the easiest thing to do would be just posting to this list - and keeping track of things you deem important. This list is what people actually read...

Personally, I've played with the idea of a total rewrite before, but I think that's way too much work now.... still some work on the db is required (as pointed out by Meir before) and would like to get started with that after worlds (or even before, by creating a special "branch" for worlds).

Klaas

[Derek Lande]

Hi,

I've been working on a list for a while of ideas I have.  These are very rough ideas and VERY pie in the sky so to speak.  Most of my ideas center around judge allocation.  Maybe these ideas may spark some discussion among others and have us come up with some innovative ideas.

This is a very rough list and I'll probably develop it a lot over time.

Derek

1. Judge Allocation
1. The ability to mark some judges with a watch flag and some with a mentor flag.  The tab should then do its best to allocate the watched judge to a mentor judge so that detailed feedback can be given.
2. When all watched individuals have been assigned to a mentor judge the tab should then attempt to assign a judge who has not judged with a mentor yet to the mentors room.  This would probably necessitate a field being added to the judges record in the database recording how many times a judge has seen
   
3. Judges should have a boolean flag indicating whether they should be allowed to chair or not.  There are some judges that I would rate as judges but view as incapable of chairing a discussion and vice-versa.
4. The tab should keep a record of the ranking of the room on the tab that each judge sees and attempt to rotate chairs between rooms of different strengths.  This should be balanced against the need to keep good judges seeing contentious rooms.  In particular this could be useful to rotate marginal chairs. Ie. Somebody who is chairing a low room one round should be given a chance to see a high round the next time.
5. Ideally manual judge redistribution should be possbile through a drag and drop mechanism.
1. There should be an unassigned pool that you can drop judges into.
2. There should be a button to clear all currently assigned chairs
3. There should be a button to clear all currently assigned panelists
4. There should be an option to take a partially completed assignment, lock those allocations and then have the tab autoallocate the remaining chairs and panelists to rooms.
6. The tab should be able to highlight contentious rooms when doing judge allocation.  There should be colour codes for the highlights.
1. 1 colour representing safe rooms where all teams have already broken
2. 1 colour representing contentious rooms
3. 1 colour representing secondary contentious rooms (ESL/EFL/Novice breaks)
7. The tab should use this determination of contentiousness when making its own automatic allocation.  In order of prioritty 1. Contentious 2. Secondary Break Contentious 3. Safe 4. Out of contention.
8. When you click on any judge in the tab an individual user profile should appear, detailing all judges who they have judged with.  In particular highlighted should be the chairs of their rooms and mentor judges should be even further highlighted.
9. There should be a watch status screen that should display a list of all those currently marked to be watched.  It should also display how many times they have been watched and by which mentors.
10. Panels should always be allocated in odd numbers. Eg. have a panel of 3 and a panel of 5 as opposed to panels of 4.
11. Any changes to judge rankings or other characteristics should contain an audit trail.  It should show who made the change and the user should ideally be given the opportunity to add a narrative explaining the reason for the change.
    
2. Teams
   
1. Should be able to record whether a team is ESL/Novice and preferably other user customisable types of team.  Eg. Some competitions only allow domestic teams to break etc.
2. If there have been complaints about a team or that teams has made complaints about their treatment there should be a watch option that would ensure that they receive a mentor class judge to judge them in the following round.
3. There should be a watch status screen that should display a list of all those currently marked to be watched.  It should also display how many times they have been watched and by which mentors.
3. Architecture
1. Granular permissions should be possible, allowing users to log in and have different rights on the system. 
   
1. Eg. Data entry only with no visibility of overall status
2. Adjudication team view who should not be able to enter results but see information that should not be visible to other views.. eg. whether somebody is marked as watched or not.
2. Every element in the database, physical rooms, teams, judges should have an option to click on it to see its full details.  This should also include space for people to record comments.  Ideally along with what user it was that added those comments.  This would be particularly useful for tracking feedback.
4. Feedback management system
1. While not wanting to get into the realm of have feedback drive the judge allocations.  A system whereby all feedback could be recorded in each individual judges profile, either through somebody capturing the key information or have somebody who scans the documents into the system.
2. This should include a workflow mechanism to ensure that the adjudication team has the ability to review all documents, see which documents have been reviewed and assign a priority level to the document to be considered.

[Deepak Jois]

Well, we do not really have a place that we manage feature requests so far. Where to manage feature requests is probably the first candidate for brainstorming.

* Sourceforge has this link where you can file requests, but I am not sure if it is good enough http://sourceforge.net/tracker/?group_id=199347&atid=969128

* We could open up a project on Google Code < http://code.google.com> , and use it for managing requests and in the long run we also could :
  * Move the wiki from tabbie.wikidot.com to Google Code (not sure how that will work though, havent done much research).
  * Move the repository from sourceforge to Google code and use Sourceforge only for file releases. (this is probably easier)

* Klaas, can the wiki pages on tabbie.wikidot.com edited by anyone? If so, we could create a Feature Requests, which could be monitored/cleaned up from time to time.

Deepak

[Klaas van Schelven]

Well, we do not really have a place that we manage feature requests so far. Where to manage feature requests is probably the first candidate for brainstorming.

* Sourceforge has this link where you can file requests, but I am not sure if it is good enough http://sourceforge.net/tracker/?group_id=199347&atid=969128

I  dislike SF in general and do not want to invest more in it :-)

* We could open up a project on Google Code < http://code.google.com> , and use it for managing requests and in the long run we also could :

I'm not sure how smart google request management is.

  * Move the wiki from tabbie.wikidot.com to Google Code (not sure how that will work though, havent done much research).

The google wiki is very very plain ..... I've tried it without much success.

  * Move the repository from sourceforge to Google code and use Sourceforge only for file releases. (this is probably easier)

SVN moves are well supported by google, though SVN is actually the least of my SF worries.

* Klaas, can the wiki pages on tabbie.wikidot.com edited by anyone? If so, we could create a Feature Requests, which could be monitored/cleaned up from time to time.

Actually, they can, but I think creating new pages has been disabled. I've created a new page here and (badly) copied Derek's stuff in:
http://tabbie.wikidot.com/feature-requests
I think that should be sufficient for now....


Klaas

Deepak