Expectations for Students

This page is meant to give a brief, though not complete, statement of what is expected of graduate students working within the Geometry and Graphics Group.  This is meant for students within the group or those considering working with the group.

As a special note, students in the non-thesis Master of Computer Science program might wish to take their courses with a focus in graphics, as described below.  The other issues would not apply to such students, as they would not generally be considered part of the Geometry and Graphics Group.  Should such students wish to take a more active role in the group (i.e. participating in research), they should expect to follow the other requirements listed below, and should probably opt instead for an M.S. degree program.

Coursework

Students considering working in the group should have already taken CPSC 441 (undergraduate graphics) or its equivalent.  If you are considering focusing on graphics for graduate study, you should have done well at and enjoyed that class.  Also, see the links on the Undergrad Program and Graduate Program for details of relevant classes.

All students in the Geometry and Graphics Group are expected to take both of the Computer Science graduate graphics classes, CPSC 641 and CPSC 645.  Only if there are unavoidable scheduling problems should a student not take these classes.  Usually additional graphics classes are required in order to meet degree requirements, committee requirements, or just to give the background students need.  All students are required to take (or have credit for) three department "core" classes.  Any selection of core classes is OK, but I would generally suggest graphics students would find CPSC 629 (Analysis of Algorithms) more useful than CPSC 627 (Theory of Computability), CPSC 614 (Computer Architecture) more useful than CPSC 613 (Operating Systems), and CPSC 606 (Software Engineering) more useful than CPSC 603 (Database Systems and Applications).  Also, all students will take the graduate seminar class.

Master of Computer Science: Students pursuing this option are required to take 6 or 7 classes in addition to the required core and seminar classes.  Should a student wish to focus on graphics, it is possible to take almost all of these from among the graduate graphics classes (see the Graduate Program link).

Master of Science (Thesis): Students pursuing an MS degree usually are required to take 5 or 6 classes in addition to the required core and seminar classes.  Two of these five should be the two CPSC graphics classes.  Most students will take the crosslisted Viz Lab classes for the remaining classes.  Masters students also have the option of taking a 400-level course for credit, and might wish to do so if they have a deficiency in some area.  See the Graduate Program link for other options.

Ph.D.: Ph.D. students may be in a variety of situations, depending on whether they arrive with a Master's degree from Texas A&M or another institution, so it is difficult to give general information.  Usually, course requirements for Ph.D. students can be met with a combination of the 6 graphics classes (the two from Computer Science and the four crosslisted from Visualization Sciences), along with a couple of others.  Ph.D. students are strongly encouraged to take 2 classes (the maximum) from outside of computer science.  Courses in Mathematics or non-crosslisted Visualization Sciences classes are good possibilities here.  Graphics is a very interdisciplinary field, and the more interdisciplinary exposure one can get, the better.

Meetings and Reports

Group meetings are held weekly, usually for an hour.  Meetings are held weekly, and the time for meetings is determined at the beginning of each semester (including the Summer semester).  Meeting times are scheduled so that Dr. Keyser can make them and so that most students can attend.  All students are expected to attend all meetings, however it is usually the case that one or more students might need to miss meetings in certain semesters due to class scheduling conflicts.  In these cases, students are expected to try to make an extra effort to follow the reports of everyone in the group.  We try to keep meetings to one hour in length, though they occasionally run longer

Meetings will generally be divided into two parts.  The first part will be for everyone to give a brief summary of what they've worked on.  The main goals here are to allow students to keep up with each others' work, as well as to allow group members to present problems they'd like help with, or give opportunities for collaboration with other students.  The second half of meetings will be a more in-depth focus on a particular topic.  This may be a student presenting current research status.  Other times, we might schedule practice talks for students about to present at a conference, or have discussion periods to review papers from recent conferences.

Students will generally be expected to handle the in-depth discussion in the research group about once a semester.  Unless that time will be a practice conference talk, this is usually a presentation of individual research.  This is not meant to be a finished research presentation, but rather to give more depth about each student's work, and allow for more detailed discussion about particular problems.  If you are scheduled, you should plan for about a 15 minute presentation, to allow for plenty of time for discussion.  Although there a standing reservation for a projector should be in place, you should check at the CSG helpdesk to make sure one is on its way on the day you present.

Weekly written reports are required from every member of the group.  These are an expected part of your participation in the group.  These reports should be sent to all other members of the group, generally via the email list that is distributed.  Your weekly report should contain:

• A list of the specific things you accomplished research-wise (e.g. new idea or thing you got working) or group-wise (e.g. something done for the group, like updating website) in the last week

• A list of the immediate short-term goals, that is the things you plan to do in the next week

• A list of longer-term goals, i.e. where are you trying to head with this.  This should be more specific than "finish thesis" (unless you are in your last semester).  Things to put here are targeted conference submissions with topics, paper deadlines, etc.

• A list of hours spent working on research or group activities over the last week, and over the semester to date.  See below for expected hours.  This is not meant to beat you over the head or anything, but to help you (and me) keep track of how much time and work you've actually been spending on research work.  If you find it useful, you might want to divide your hours into topics (such as "research" and "infrastructure").

Publications

Although the department does not currently have publication requirements for graduate students, such an idea has been considered in the past.  This is intended to give an idea of the expectations for group members in publication, as well as some of the rationale behind publishing your work.

Reasons for Publication: Many students have a hard time understanding the reasons for publishing work.  There are several reasons for publishing, and an important part of a graduate career is understanding this:

• Distribution of Knowledge: Although this sounds grandiose, the major reason to conduct research is to expand the realm of human understanding.  It does very little good to work on something and not communicate it to other people.  There are many possible ways of communicating results, but the primary one used in academic circles is through publications in conferences and journals.

• Evaluation of Work: Most forums for publication offer some type of peer-review.  Others judge your work, comment on it, and make a judgment as to its significance.  So, the review process offers an external "reality check" on how significant your work is.

• Recognition of Work: In an academic environment, publications are, for better or worse, used as a measure of the level of achievement for a particular individual.  Regardless of how good someone's work is, without publication (which involves an evaluation by others that the work is significant, and demonstrates that the person is committed to distributing such knowledge), it is much more difficult to establish that someone is doing worthwhile work.

• Procedural Experience: Often, understanding is deepened when trying to explain something to someone else.  Writing up information for publication forces one to describe work coherently and completely, as well as to make convincing arguments for its contribution.  This can help to highlight shortcomings, and ultimately leads to a deeper understanding of the material.

Forums for Publication: There are numerous methods for publishing results, some more appropriate than others.  These include:

• Selective Conferences: In computer science, the primary method for publishing results is in selective conferences.  These conferences usually have a thorough peer-review system in place, and are well-known as the sources of research results in particular fields.  There are also less-selective conferences (see below), and although there is no strict division, they should not be confused.  One can usually tell the difference by examining the peer review process, the percentage of accepted papers (less than 40% tends to be selective), the people on the program commiteee, how often the results are cited by others, etc.

• Journals: Journals are the traditional method for publishing results in academia.  They have become somewhat less important (I would argue much less important) in computer science, as selective conferences tend to be the outlet for most research, but are of primary importance in other fields.  Like conferences, journals are peer-reviewed to various levels, with some being easy to get into and others more difficult.  Also, like conferences, journals will have specific focus areas, and will be more or less known as outlets for finding results.  Journal results generally take a longer time to prepare, to have reviewed, and to appear once they are accepted.  They also are more iterative processes - a submission can be returned for corrections, and several more iterations made, with eventual publication.  In some cases, the reviewing is more thorough than for conferences, though the chance to resubmit often makes a journal submission "easier" than a conference one.  For particularly large papers, with more details than can be included in a conference paper, a journal is appropriate.

• Theses/Dissertations: These are reviewed by a committee, and are made publicly available.  Sometimes theses and dissertations can have a wide impact, but in practical terms, they do not usually have the impact of conference and journal publications, for the simple reason that those outside the University they were produced at are unlikely to encounter them directly.  Often, a thesis or dissertation expands on and ties together results published elsewhere, anyway.

• Software Release: Software release can be an excellent way of spreading research results, particularly when it is an application that many people are likely to find useful.  Useful software releases often require a great deal of care in coding and documentation, however (I have heard a rule of thumb that it takes 10 times the work to have a good release as to have an initial implementation).  If a software program becomes widely known or used, however, it can meet the same goals as other traditional forms of publication.

• Posters: Several conferences have poster sections.  These can be excellent ways of advertising work, presenting initial results, or describing minor results (not ready to be in a full paper).  Sometimes conference proceedings will include a peer-reviewed short paper or poster abstract; these can be cited in the future.  Other times there is a less-reviewed separate "poster proceedings" at a conference containing the abstract.

• Technical Reports: Technical reports are easy to generate and have no review standard.  Basically, when you have work or a portion of work in a complete form, it can be written up as a technical report.  A number can be assigned by the department here, to "register" the report, making it easier to refer to and index.  Technical reports are not to be considered on the same level as other publications, as they have not had undergone the peer-review process of other papers.  They can be useful, though, for getting ideas "out" or for presenting results that for one reason or another will not be published soon.  Examples of the latter might be that the results are still initial or not significant enough on their own, that they are too detailed (they might be cited by another publication, though), or that they are meant to be explanatory/instructive (rather than novel research). Technical reports are good places to present details that would take too much space/time in another format, or to release initial results that so that they can be established and cited elsewhere.

• Workshops: Workshops tend to be less-formal (and usually smaller) gatherings of researchers.  Usually the workshops consist of a number of presentations by the attendees, with the idea to foster the interchange of ideas.  Usually there is no "proceedings" other than an abstract, though sometimes a reviewed volume may be produced from contributed papers from the workshop.  Workshops can be a good forum for presenting and discussing ideas, but (unless there is a special book/journal issue produced) are not really forums for publication.

• Less-selective Conferences: Besides the more selective conferences, there are also several less-selective conferences.  These tend to have only minimal peer-review of papers, accept large percentages (often 80% or more) of papers, etc.  Because there is so little review of these papers, few researchers really pay attention to the results of such conferences.  As a result, they are generally not very useful means for publication, as they don't meet most of the main reasons for publishing.

• Books: Books and book chapters are excellent means of publishing, but usually not something grad students do.

Publication Expectations by Year: Within the Geometry and Graphics Group, students are expected to continuously be working on research with an eye toward publication of the results.  The exact expectations for publication may vary by person, but this should give an idea of what I would expect.

For students in their first year in the group (particularly coming from an undergrad program), it is not necessarily expected that any publications will be attempted.  However, if possible, students in their first year should seek to get involved with an ongoing project, possibly contributing to a submission as part of someone else's paper within their first year.

After the first year, students should generally be aiming to make at least one solid submission to a selective conference or journal per year, with that student as primary author.  If you have been working on a research topic for a year, it is reasonable to expect that you would have some results by the second year, and new results each year thereafter.  In addition, students ought to continue to look for ways to assist with other students' work.

For Ph.D. students who have been here a few years (particularly once most coursework has been finished for a year), there is a good chance that students may be able to make more than one solid submission in a year.  This will depend on the level of collaboration with other students, of course.  At some point, Ph.D. students should expect to submit some work in journal format.

Publication Expectations by Graduation: The following are not hard and fast rules, but are meant to give an idea of what would be considered minimal (you should try to have this at a minimum), good (this would be a "solid" result from your graduate work), and excellent (this would be notably above average) progress. Of course, the quality of publications may also vary: one top SIGGRAPH publication might be more important than a couple of lesser ones, for example.  Other times, maybe posters or short publications might be created.

• Master's Students: Usually, the M.S. thesis will be an expanded version of some paper (or the paper is a condensed version of the thesis).  Thus, papers may often be published after the thesis is finished.

  • Minimum: Submitted a paper as primary author to one conference.

  • Good: An accepted paper as primary author to a conference, plus another submitted as primary author or coauthor.

  • Excellent: Multiple accepted papers as primary author, or one as primary and multiple as coauthor.

• Ph.D. Students: Often, the Ph.D. dissertation collects together several papers already or pending publication.  Often, some papers resulting from dissertation work are not published until after the dissertation.

  • Minimum: A couple of papers in conferences as primary author, and one paper submitted to a journal.

  • Good: Multiple (3+) papers published in conferences and some (1+) in journals as primary author, with some others (2+) as secondary.

  • Excellent: Several (4+) papers published in conferences as primary author and multiple (2+) journal articles published, with others as secondary (total of 10+), and more of each pending.

Author Listing on Publications: Students may have some question on how authors should be listed on papers.  The convention for this varies by subject, but this is a common one in computer science, and that I have generally followed.

The first author listed should be the one who has done the primary work in the paper (the "primary author").  Generally, this is the student who took the lead on the project, but in case this person is unclear, it usually helps to assign a single primary author to each paper, and make the paper reflective of that person's input.

The final author should be the advisor.  In cases where a single student has done all work on their own, without much consultation with an advisor, it might be appropriate to leave off the advisor's name on a submission.  However, in a "usual" sense, where a student has worked on a project with an advisor, and the advisor helped through discussion, the advisor's name is listed last.  If there are multiple faculty advisors, these can be listed alphabetically at the end.

Names in the middle can be either listed alphabetically or in order of contribution.  Usually alphabetically is preferable, as it can be difficult to assign weight of contribution beyond the primary/secondary designation.  Others should be listed here only if they made a significant contribution to the novel research results presented in the paper, i.e. if they played an active role in the research the paper deals with.  This could include aspects such as coding up examples, or more fundamental contributions to the paper.  Providing help with figures, formatting, and the like, or with discussion on single topics, can be acknowledged in a separate "acknowledgements" section in the paper, rather than as a coauthor; coauthors are only those who have made contributions to the research itself.

Finally, acknowledgement should be made to funding agencies.  The Geometry and Graphics Group exists in part thanks to funding provided, and even if you are not a paid RA, such funding may play a role in your work (such as funding facilities, or more directly, travel to present the results at a conference!).  Unless you have a single-authored paper (i.e. no advisor listed), and were not paid as a research assistant, you should include this acknowledgement.

Web Sites and Distribution

The Geometry and Graphics Group website, which you are reading now, is intended to grow into a resource for both current group members, future group members, and those outside the University interested in our research.  It is the responsibility of each student to maintain their own portion of the website related to their research.  In addition, another student might be assigned to perform general website maintenance.  Every student should have access to the web space this lives under.  There are three portions of the website that you will need to be aware of:

First, each member has a link to a personal web page.  This web page should contain information about you, including how to contact you.  You can make this a link to a page you already have/maintain, or can create a personal page on the group website.

Second, there is a Papers link.  Papers that are published (including technical reports) should be added to this page.

Third, there will be a set of project web pages.  The idea here is to put information about each research project, so that others can find out details.  If multiple people work on a project, someone should be designated to keep this part maintained.  When you leave, you should leave this page in an archival format, so that people who want to pick up the project after you can do so.  The information that should be included on this page is:

• A title for the project.

• A brief summary (one long paragraph) giving the motivation and goals of the research.

• A few sample images (if available) to give a visual impression of what's being worked on.

• A list of individuals involved in the project

• Links to any papers or technical reports about the work.

• Links to any software that can be downloaded related to the project

• (Optional) - A list of papers (from other people) and/or resources that someone wanting background on the project could use.  This would be mainly for those group members who want to learn more or get up to speed on the project.

I realize that this will take some time to come into place, and do not expect immediate results, but students should be able to keep this moderately up to date within a couple of months.

Hours Spent

Progress in graduate school is not a strict function of the number of hours you put in. It is rather a function of how much progress you make in your research and writing; graduation is achieved by completing the requirements, rather than just taking hours.  In a sense, the hours spent are meaningless.  If you prove P=NP on one page with one hour of work, you could write an ultra short dissertation and leave with your Ph.D. very quickly.  Or, you could work for years, make no progress at all, and never graduate.  In general, though, it is often helpful to know what the "expected" level of work is in graduate school.

Assistantships are meant to take "half a work week", or 20 hours a week of your time.  If you have a research assistantship, that time should be spent on research.

A usual rule of thumb is that one hour of class time should require 2-3 additional hours of work outside of class.  Thus, each hour of research credit means spending a total of 3-4 hours of total time per week on research (since there is no "class time").  With a semester occupying 15 weeks (14 of class and one of finals), you should therefore expect to spend 45-60 hours per semester per hour of research credit taken.  Doing the math, you will realize that taking a full load of research (9 hours), which is supposed to be "half your time" is not a 20-hour a week, half-time job, but rather on the order of 27-36 hours per week.

As stated above, you are asked to account for your time spent on research work in your weekly report.  This is done in large part for your benefit.  These numbers are given as guidelines for what you might expect to spend, and  how you can tell whether you are spending more or less than you might be expected to in making "average" progress.  Keep in mind, though, that progress is measured more by results than by hours.  Note that "research" time can include several things besides sitting and thinking/coding/testing/writing.  Group meeting attendance is considered part of your "research" work, as are things like attending relevant seminars, maintaining a project web page, reading papers, or assisting other group members.

Finally, in keeping track of hours spent on research, you might find it useful to keep track of hours in two areas.  One would be "core research", the time spent on your own research topic, whether doing background work, development, or writing.  The other area would be "infrastructure", which would include things more for group benefit (including meetings), such as maintaining the group web site, managing group accounts, assisting others with issues (e.g. putting together models for group use), etc.  Infrastructure work is important, as it helps the entire group to function more efficiently.  You might expect to spend as much as half your time on such infrastructure issues.