Menu Close

FAQs for (new) faculty

[av_toggle_container initial=’0′ mode=’accordion’ sort=”]
[av_toggle title=’What does my office key open?’ tags=”]
Your office key is for your office space (opens both the door to the suite and the door to your office). Your other key opens the mailroom and the POST 302 conference room.  To enter the building when all outside doors are locked (which happens rarely), you must obtain the combination code for the one keypad entrance door (on the Ewa-Makai side of the building). Contact the ICS Chair for information on how to obtain the code.
[/av_toggle]
[av_toggle title=’How do I communicate with others in the department?’ tags=”]
The LIS and ICS department were originally two completely separate programs that were joined together in 1997 (see A brief history of the department).  We have continued to use the two mailing lists in existence at that time for faculty communication:

  • lis-fac@lists.hawaii.edu.  A mailing list to faculty in the LIS program.
  • uhm-ics-faculty@lists.hawaii.edu.  A mailing list to faculty in the ICS program.

To send mail to both programs, you  send mail to both email addresses.   Contact the respective chairs of ICS or LIS to request changes to the membership of those lists.

There are a variety of additional mailing lists to students in each department.  For access to ICS undergraduate student mailing lists, contact Gerald Lau.  For access to ICS student graduate mailing lists, contact the ICS Graduate Chair (currently Edo Biagioni). For access to LIS student mailing lists, contact Rich Gazan.  You can either ask them to forward information to the lists, or ask to be added as a sender so you can send information directly.
[/av_toggle]
[av_toggle title=’How do I add or edit (non-news) information on the department website?’ tags=”]
There are two primary websites for the department. The www.ics.hawaii.edu website contains general information about the department as a whole as well as specific information about the computer science program.   The www.hawaii.edu/lis website contains specific information about the library program.

If you would like an account on the www.ics.hawaii.edu website in order to add information, please contact Henri Casanova.  It is highly recommended that our faculty get accounts to add information to our Web site themselves when it simply involves adding content to an existing page (the WordPress interface is intuitive).

If you would like an account on the www.hawaii.edu/lis website, please contact Andrew Wertheimer.
[/av_toggle]
[av_toggle title=’How do I add descriptions of ICS491/ICS691 courses to the ICS Web site?’ tags=”]
Course descriptions for Special Topics courses (ICS491/ICS691) are listed for each semester on this page: http://www.ics.hawaii.edu/academics/selected-course-descriptions/

These descriptions consist ideally of:

  1. A course title and the name of the instructor (example: “ICS691, Formal Method, Prof. Seidel”)
  2. A few lines of high-level description
  3. A link to a Web page for the course  (if no Web page is provided, then the high-level description should be a bit more extensive)

To add this description you must edit the above page while logged in to the Web site. If you do not yet have a WordPress account for the ICS Web site, see FAQ #3.
[/av_toggle]
[av_toggle title=’How do I publish a news item to the ICS website?’ tags=”]
Please see this page for detailed instructions.
[/av_toggle]
[av_toggle title=’What infrastructure support exists at UH for site hosting?’ tags=”]
The Information and Technology services department provides two primary hosting services: (1) a high-level website hosting service (for people who want to build simple static websites using WordPress or Drupal); and (2) a low-level virtual server hosting service which provides you with the ability to configure a virtual host with an OS, CPUs, RAM, disk space, etc.

For more information on the website hosting service, see Philip Johnson’s blog post.

For more details on the virtual server hosting service, see the ITS documentation page.
[/av_toggle]
[av_toggle title=’What are useful resources for relocating to Hawaii?’ tags=”]

Apartment search: padmapper.com
Temporary housing on campus for faculty and visitors: http://www.eastwestcenter.org/about-ewc/housing/housing-facilities/lincoln-hall
Temporary housing for visitors: https://www.airbnb.com
Pet move service: http://islandpetmovers.com

[/av_toggle]
[av_toggle title=’How do I get access to Hamilton Library classrooms?’ tags=”]

Using Hamilton Library Classrooms for a Class

To schedule a course in a Hamilton Library classroom, please contact Gerald Lau. He will work with the LIS Program Chair if the room is available. LIS courses are usually offered 9-11:40am /1-3:40pm/ 5-7:40pm, with the evening being the busiest time slot. The LIS Program schedule is online, but this schedule does not include CIS or other ICS classes.

The LIS Program Chair will work with you about security and food regulations relevant to using Hamilton Library. You are responsible for cleaning up after yourself, and making sure the area is locked and lights are out if you are the last one there on an evening or weekend. Please also make sure that the computers/ projectors are the way you found it for the next user.

Using Hamilton Library Classrooms for Meetings or Other Events

If you want to schedule a thesis defense or other meeting in the LIS Program, please e-mailslis@hawaii.edu and the LIS Program will get back to you. In your e-mail please indicate your name, why you need the room, and which room you are requesting. We have three classrooms: 2K: Technology Classroom can seat around 20 students and has around a dozen PCs. 3F is the large classroom, and can hold 25-30 students. 3G is a seminar room which can hold 15 students.

The LIS Program Chair will work with you about security and food regulations relevant to using Hamilton Library. You are responsible for cleaning up after yourself, and making sure the area is locked and lights are out if you are the last one there on an evening or weekend. Please also make sure that the computers/ projectors are the way you found it for the next user.
[/av_toggle]
[av_toggle title=’What is UHARI?’ tags=”]
UHARI (University of Hawaii Association of Research Investigators) is an an hoc mechanism for representing the general interests of extramural grant principal investigators (mostly faculty, and some administrators) at the University of Hawaii. It is has been in existence since 1997, though it tends to be dormant when the UH research enterprise is running smoothly.

The UHARI mail list exists to facilitate communications within the research community across all campuses of the University of Hawaii. The list includes faculty, staff and administrators who “opted in” to the communications flow. When problems arise (for example, with the MyGrants system in 2013),  active discussion on the UHARI list resulted in improvements to the research environment at UH.

From time to time, UHARI has also organized meetings with university officials to discuss the  research environment. These meetings have also been highly productive.

Membership in UHARI is free. To join or update your email address, send email to Roger Lucas (rlukas@hawaii.edu). Anyone who wishes to leave the list can unsubscribe themselves through the UH listserv management system.
[/av_toggle]
[av_toggle title=’Can I get a mentor? ‘ tags=”]
Yes!   The ICS Department tries to pair each new junior faculty member with a compatible senior faculty member to help you transition into the department.   Please contact the Department Chair if the Chair has not already contacted you about ICS mentoring.

In addition, the UHM campus runs its own faculty mentoring program, which involves not only direct mentoring but also events throughout the year to help you be as effective and productive as possible.  See the UHM Faculty Mentoring Program website for more details.
[/av_toggle]
[av_toggle title=’How do I find/create an ICS Technical Report?’ tags=”]
ICS Technical Reports are hosted on ScholarSpace.

This archive has been used infrequently in recent year, likely due to the popular use of arxiv for publishing technical report.  Note also that several labs in the ICS Dept. maintain their own publication pages (see this page for pointers).

The current person of contact for ICS Technical Reports is Prof. Henri Casanova. If you wish to submit a technical report, you will need to provide him with: (i) title (plain text); (ii) list of authors (plain text); (iii) abstract (plain text); (iv) PDF of the report.
[/av_toggle]
[av_toggle title=’What is RTRF?’ tags=”]
RTRF (Research and Training Revolving Fund) is the money that is budgeted to the University of Hawaii as “indirect costs” when you are awarded a grant.   For example, if you write a proposal to the National Science Foundation for $100,000, your 2014 budget would need to set aside 40%, or $40,000 as “indirect costs”, leaving you only $60,000 to allocate directly to your research activities.

The indirect cost percentage is rising over time.  See this link for a page detailing the rates for the next several years.

As the researcher responsible for generating that money, it is in your best interest to understand what happens to it. Fortunately, the Vice Chancellor for Research at Manoa is required to create a report every year documenting how that money has been disbursed.  Here is a link to the RTRF Report for 2013.

What that report says is that in 2013, 75% of the total amount was returned by the UH System to the Manoa campus, and 66% of that amount was returned to the “units” (in our case, the College of Natural Sciences).

So, out of our hypothetical $40,000 in indirect costs that we were given from NSF, $30,000 made it back to UHM, and $20,000 made it back to the College of Natural Sciences.

The Dean of the College of Natural Sciences then decides what to do with the money.  While the decision varies from year to year depending upon budgetary demands, the Dean historically returns a substantial percentage (on the order of 50%)  back to the originating Departments.   So, that means that approximately $10,000 of your indirect costs are now back in ICS.

The Dean typically informs the Chair of ICS of the annual RTRF funds to be put under ICS control in late October. Each year at this time, the Chair of ICS must decide what to do with this year’s ICS RTRF money.

Once again, the decision varies according to the budgetary situation.  Typically, the ICS Chair calls a meeting of the ICS principal investigators (PIs) who have generated RTRF funds this year, and distributes a spreadsheet showing how much RTRF each PI has generated that is now under departmental control.

There have been a few lean years in the past where the Chair has needed to use all of the RTRF money to maintain basic department services.  Fortunately, in recent years the ICS Chair has provided half of the funds directly to the generating PI, leaving the other half as a pool of money to support research-related departmental expenses (such as travel, equipment, etc.)  The PIs who generate the money each year become the committee that makes decisions on how to allocate the pooled money for that year.

So, out of our hypothetical $40,000 in overhead, $10,000 has been returned to the Department.  Of that, $5,000 is back in your hands to spend on your research, and the other $5,000 becomes part of a pool of money to support research endeavors.

The moral of the story:  the more you generate in grants, the more RTRF you get to spend.
[/av_toggle]
[av_toggle title=’What is the 2015 RTRF spending policy?’ tags=”]
On February 2, 2015, faculty who generated RTRF money were invited to a meeting by the Department Chair to discuss how to allocate those funds in 2015.  Here are the results of that meeting:

50% of the RTRF money returned to the Department by the College is reserved for use by the PI who generated those funds.

For 2015, that leaves approximately $16,000 in RTRF money in a general “pool” to support research activities in the Department.

The committee decided to dedicate this “pool” money to a travel fund for research-related conferences and workshops. (Other research-related expenditures such as computers, publication costs, etc. must be funded from some other source.)

Faculty and students are eligible to use this fund only if they do not have grant funding for research-related travel.

Travel funding for each faculty or student is capped at $1500 per year.  You cannot “give” your allocation to another faculty or student so he or she can do an additional trip. If you need less than $1500 for your first trip, you can apply again up to a maximum of three trips or $1500 total.

Travel must be to a conference or workshop related to a faculty or student’s research for the purpose of “participation beyond mere attendance” (e.g. presenting a paper, poster, or invited speaker).  Chairing of sessions or tracks does not qualify.

Faculty and students are expected to apply to other funding sources as well. For students, please apply to the GSO Grants and Awards program. For faculty, please apply to the University of Hawaii Faculty Travel Fund.  Many conferences also have special funds for students: please apply if you qualify. It is OK to request ICS RTRF support for travel at the same time that you request funding from GSO or UH.  If it turns out that you can obtain travel funding from another source, please use it as much as possible so as to preserve the ICS RTRF funds for others.  If UH or GSO does not fully fund your trip, it is fine to use the ICS RTRF fund for the remainder.

Awards will be given on a first-come, first-serve basis until funds are depleted. Please do not apply until your paper or poster has been accepted.

For 2015, the Associate Chair (johnson@hawaii.edu) volunteers to administer this algorithm. Please send your requests to him.
[/av_toggle]
[av_toggle title=’Is there an ICS letterhead template?’ tags=”]
While there is no “official” ICS letterhead that you are required to use, there is a sample letterhead file provided in the ICS Logo Directory. Check the subdirectories for graphics snippets if you are rolling your own.
[/av_toggle]
[av_toggle title=’How do I get Microsoft software?’ tags=”]

The ICS Department is a member of the Microsoft DreamSpark program, which enables students, faculty, and staff to free academic licenses for Microsoft operating systems, developer and design tools, applications, and servers.

To obtain access to the DreamSpark program, contact Nolan Oshiro.

[/av_toggle]
[av_toggle title=’How do I create a home page?’ tags=”]
There are many options for how to create a personal home page (or a lab page). Here are just a few to get you started:

1. UHUnix.

You can login to uhunix.hawaii.edu, create a public_html directory, and put an index.html file in there. This will display your page at http://www2.hawaii.edu/~username. For example, here is Nodari’s home page at: http://www2.hawaii.edu/~nodari.

2. ITS WordPress installation.

The UH Information and Technology Services also supports free hosting of WordPress sites on its infrastructure. If you want to build a more complex site, this might be a good option. See Philip’s posting on setting up a UH WordPress hosted site for more details.

3. GitHub Pages.

It is possible with GitHub and Jekyll to set up a nice “static web site”. Here is an example home page by a former ICS student, John Bender, at http://johnbender.github.io.

4. WordPress.com

If you are tenured and have superfluous time and money on your hands, you can buy a domain name and set up your own site. For example, http://philipmjohnson.org.
[/av_toggle]
[av_toggle title=’How do I enter registration overrides for students?’ tags=”]
Some students may encounter registration errors when trying to register for your courses, and the registration system tells them to contact you for an override.

See this page for a list of registration errors students can encounter (often, that page will say that students should ask the instructor to enter a particular kind of override, which is what this FAQ is about).

In several cases, an override is justified (e.g., your class is full but you’re OK having more students in it, a graduate student hasn’t taken the undergraduate prerequisite for a graduate course because their undergraduate degree is not from UHM, a student has not taken the required prerequisites but you deem that they have the necessary background to take your course, etc.).

When granting the override is warranted, here is how you do it:

  1. Go to MyUH (http://myuh.hawaii.edu) and log in with your UH username and password.
  2. Once logged in, in the left navigation panel click on “Override Code Entry”.
  3. This will take you to a sequence of pages in which you select the Term, the student ID (or UH username), and finally the overrides themselves.
  4. For each override you want to grant, select a course. This is easy since MyUH knows which courses you’re teaching and gives you a convenient pull-down menu.
  5. You also have to pick the type override you want to grant. The override pull-down menu has many options (and is initially set to None), but don’t panic, only a few options are relevant for you. To simplify things, you need only select one of the 6 override types that begin with the word “Manoa” (although some of the others do work). These overrides are described below, not in the order in which they occur in the pull-down menu, but sorted from most useful/common to least useful/common:
    • Manoa Closed Class Override: All seats in the course are taken, and by selecting this override you grant the student a seat beyond the course capacity. (You must make sure your classroom can hold the extra student, and consider your TA workload.)
    • Manoa Dup/Repeat Course Override: This is to allow a student to repeat a course when the repeat limit has been exceeded. This is really useful since our students can take ICS491 and ICS691 multiple times as these courses are about different topics. (As a reminder, a BA student can only count one ICS491 course toward graduation.)
    • Manoa Course Approval Override: This is typically the override you enter to allow a student who has not taken the prerequisites into the course. Also, some courses are set up to require that all students obtain instructor approval via an override. Such courses don’t exist or are rare in our program.
    • Manoa Level Override (Chair): This (powerful) override is to allow a student not in our program to take a course. This applies for CIS students, EE students, unclassified graduate students, etc. Note that with this override you could in principle let anybody into your class. If unsure, it may be a good idea to check with the undergraduate or graduate chair about this before entering the override.
    • Manoa Time Override (College): Students get a registration error whey they try to register for courses that overlap time-wise. This can be a dangerous override not only because the student will miss part of some lectures, but also because the final exams may conflict. It may be a good idea to check with the undergraduate or graduate chair about this before entering the override.
    • Manoa Corequisite Override: Corequisites are courses that must be taken simultaneously during the same semester. Our program does not have corequisites, so you’ll likely never need to select this override to allow a student to not take corequisites simultaneously.
  6. Note that clicking “Submit” will take you to a page that shows your selection and that you have to click “Submit” a second time for the overrides to be entered in the system.
  7. When in doubt, it’s common practice to enter multiple overrides to make sure you hit the one they need (e.g., Level and Course Approval to allow a CIS student without prerequisites to take an ICS course).
  8. In some complicated/exceptional cases the above may fail. In this case you have to talk to the undergraduate/graduate chair to resolve the issue.

[/av_toggle]
[av_toggle title=’How do I bootstrap a software development team?’ tags=”]
For Philip’s response to this question, please see his blog post.
[/av_toggle]
[av_toggle title=’How do I get a key to the POST building?’ tags=”]
It may happen that all doors to the POST building are locked (e.g., at night, during breaks). It is possible to request a key to the POST office from the ICS main secretary.   Note that you can also call campus security and they can come open the building for you if you happen to be locked out and don’t have a key to the building.
[/av_toggle]
[av_toggle title=’How do I set up my computer to use the ICS Office printer?’ tags=”]
To use the ICS Office printer, please consult one of the following guides based on your OS:

[/av_toggle]
[av_toggle title=’What are tips for writing NSF proposals?’ tags=”]
A faculty email thread in Spring, 2016 presented various faculty thoughts on the NSF proposal writing and evaluation process.

from Philip Johnson:

I recently participated in an NSF Panel review. It occurs to me that junior faculty, and/or those who have basically given up applying for NSF funding due to the very low award percentages, might find these observations of interest.

Let me start with some general comments about the process.

(1) Here’s the basic math for a typical program. Assume NSF has $20M allocated for a solicitation, and the average submission request is $500K. So they know they can fund about 40 proposals. Now, let’s say 400 proposals come in, so they now know they can fund 10% of the submissions. To winnow them out, NSF forms 20 panels who will each rank 20 proposals, and they instruct each panel to figure out which of the 20 are the top 10-15% for the program officers to move forward in the process. (Winning your panel doesn’t automatically mean you get funded, but it raises the odds dramatically.) Notice that your proposal, at least initially, does not compete against 399 other proposals, it only competes against 19 others, and your goal is to beat 18 of them. This also means that chance plays a role: some groupings will have stronger competition than others.

(2) Unless the proposal is really bad or really off topic, the panel tries to answer this question: “What should be fixed for resubmission so that it will get funded next time?” It’s hard for you to predict and address all the issues that will arise to panel reviewers in your first submission. Don’t be afraid to make improvements, revise and resubmit again. One of my friends who is a Rock Star Researcher in SOEST told me that for a proposal he really believed in, he resubmitted a half dozen times over 10 years before finally getting it funded.

(3) If your proposal is declined, read over the reviews, wait for just a day or two to let your anger and frustration subside, then pick up the phone and get in contact with the program officer. Calmly ask them questions from the perspective of how to improve the proposal for next time, and see if there are other solicitations in the pipeline you should know about. They will not be irritated that you called! Their JOB is to help the scientific community write proposals that get funded.

In summary, NSF funding is now a multi-year, multi-submission process for most of us. Don’t think that after your first submission, you can just address the comments and it will definitely be funded the next year: it is very common for the second panel to pick out entirely new issues as a reason to decline. But, over 3-4 submissions, you should start to see either the proposal getting stronger reviews or else fundamental weaknesses re-occurring in the feedback.

Now let me turn to issues in proposal structure and content:

(4) You need to “thread the needle” on the research problem to be addressed: it’s bad if it’s so low risk that it comes off as “incremental”, but don’t go so far that the committee thinks “this is three proposals worth of research”.

(5) For larger proposals, team composition is really important. Make sure you include at least one person with a track record for each of your core problem domain areas. If an expert for a core problem domain is missing from the team, indicate someone that you will collaborate with at least informally to give the panel confidence your team won’t be naive about important issues.

(6) Make sure you have relevant, recent citations. Reviewers look at the citations and your bibliography closely, and sometimes look up and read/skim the papers. If your only citation for an area important to your research is from 1980, that raises a red flag.

(7) The evaluation plan is a common point of weakness. As a rule of thumb, try to get to the level of detail of the kind of statistical analysis you will perform on the data to confirm/deny your research hypothesis. This will also force you to describe your experimental design in some detail.

(8) Condense your Results from Prior NSF support; it should not be multiple pages. If it is, reviewers will wish more pages were spent on details of the work you plan to do.

(9) With respect to broader impacts, it is easier to make the case for attacking a really important problem, than to make the case that you’ll solve a relatively narrowly scoped problem but that in future it could be extended to many other problem domains.

(10) If you are collecting data, it’s important to address security and privacy issues unless there are obviously none. At least acknowledge they exist and articulate the kinds of precautions you will take while collecting/storing the data.

(11) The current fad is machine learning. Don’t just “throw some machine learning at it”. If you’re using machine learning, go into details on the approach you’ll use, and justify it.

(12) Be sure your orient your research so it fits the solicitation and/or program area. Reviewers will pick up on proposals that look like they were recycled without any significant effort to tailor them to the current solicitation.

from Jason Leigh:

Iʻve been serving on NSF panels twice a year for over 10 years (ugh) so here are my observations:

– Just because 15 pages is the limit doesnʻt mean you gotta fill them all. Reviewers rarely read the entire proposal. Jamming as much text as possible into the 15 pages doesnʻt mean you cover all your bases better. It just means you annoy the reviewer more if all that text is just densely packed technobabble. Think of the proposal as a user interface like on a computer. Putting up a poor one will frustrate them. And reviewers have to review between 10-12 proposals.

– Donʻt make the reviewer work to find the answers to answer the NSF review criteria. Help the reviewer by making it easy for them to almost cut and paste your answers to fill the criteria. Donʻt make them spend extra effort to search thru the whole document and reinterpret your text to fit the criteria. Spell it out blow by blow.

– 90% of the proposals Iʻve reviewed are in an area that I am not an expert in (even when I am reviewing for CISE). So you have to explain things to laymans too. A good strategy is to write it like a newspaper article. High level summary first, then repeat with a little more detail, and then with even more detail if necessary.

– The shortest reviews are generally written by the most senior reviewers. The younger reviewers tend to be harsher. The loudest reviewers tend to bias the group regardless of whether they have a valid point or not. Senior reviewers tend to be more positive. Junior reviewers tend to be more negative. Ironically itʻs the same in Kendo. When I was going thru my second degree exam, the senior sensei were always the least critical. Anyway I digress.

– Overall being negative on review panels about your proposal makes you seem more intelligent to the panel (unfortunately) even though your point may be completely invalid. Also being negative on the proposal gives the program manager a harder time to justify why they should support a proposal. Other disciplines have learned not to eat their own. Computer Science still has not. So when the big proposals bubble upstairs and are compared across directorates CS gets the lowest scores because we kill each other. So then who would they support? Of course the disciplines with lots of glowing reviews. Iʻve had program managers admonish review panels for killing their own community. Now that said, there are some cases where program managers will say “proposal pressure here does not help increase future funding, so you can be more critical”.

– A review panel is not the time for you to show how smart you are. No one cares. Say your peace and move on. Donʻt waste everyoneʻs time by saying how terrible proposal is knowing full well it will never be funded given all its reviews. This is not a time for catharsis. We all want to get thru this and go home. The earlier we finish the earlier we can take the early flight. NSF flights are booked as government flights so there is no cost in changing for an earlier flight. So after the first day of the panel, it is worthwhile to go to your hotel room and write your panel summary so you are ready the next morning to go thru them. Too many panelists start writing them the next morning, which means everyone has to stay longer. No one is allowed to leave the panel until EVERY proposal is reviewed with a proper summary which is read to the ENTIRE panel.

– For broader impact. Itʻs not enuf to say others will use your work or it will be published. Everyone says that. If there are any entrepreneurial programs within your institution, partner with them as a means to potentially turn your research into product. I know thatʻs not what we typically do as faculty, but NSF is under greater scrutiny from Congress regarding the applicability of the research. Help them make their case. You also really need to address supporting minorities. NSF gets admonished when their panels are not diverse enough. They actively keep track of that information as well believe it or not. I.e. they want someone young, old, male, female, and of different ethnic backgrounds where possible in their review panels.

Also for Broader Impact coverage you canʻt just say we are an EPSCOR and Native Hawaiian serving institution with X% enrollment in the university. Every institution is now learning that game. You have to say what you will ACTUALLY DO to increase participation of minorities.

– As Philip says, if your proposal fails, try again and try to address the reviewers comments, though it is very hard to try more than 3 times because CS as a field, unlike other fields like Ocean Sciences, changes much more rapidly.

– Contrary to what Philip says, program managers donʻt want you to call them too much. They are busy people. Instead they want the review summary written in a way so that you donʻt have to contact the program manager for clarification. So definitely wait a day, calm down first, before you call the program manager. That said, striking a relationship with a program manager is still a good thing to do. Even though a review panel likes your proposal, these are only recommendations. The program manager does not have to fund it. It is always easier for a PM to favor one top proposal over another if he/she has already established some kind of relationship with the PI. Thatʻs life.

– If a proposal is likely to get funded you will likely hear about it within 4 months because they will usually ask you to tighten the budget a bit so they can squeeze in more proposals. If you donʻt hear from them for a long time then itʻs a pretty good indication that it was rejected.

– If you are a junior faculty and you receive an invitation to review a proposal for NSF, DO IT. This is how you learn what goes on. In general 2 panels per year is normal. 3 is too much. For Junior faculty 1 is enuf.

– If you are including diagrams, make all labels no smaller than NSFʻs minimum size (by the way 11 point Times is the most compact font that meets NSF requirements). I know we all like to squeeze in tiny diagrams into the proposal. If the reviewer struggles to read it, then itʻs a bad user interface, and as I said before, youʻll just annoy them. Similarly for charts and graphs. Just because the chart takes up a lot of space does not mean you can now use 2 point font.

– In general if you donʻt get at least Excellents and Very Goods in your reviews, youʻre not going to get funded. Unfortunately when reviewers review something that is not in their field they tend to give proposals weaker scores- because they are less confident in their review. It is not fair to poorly judge a proposal when the reviewer is at fault. But thatʻs life, which goes back to my point about making sure the reviewer, even though he/she is not in your field, can understand the importance of your research without having to understand a lot of technobabble. It is not the reviewers responsibility to go read up on a subject in order to review a proposal. NSF will thank you for the effort but their rules stipulate that you are only to review the proposal based on information provided in the proposal.

– Reviewers rarely read the solicitation. So it is your job to specifically re-mention the requirements of the solicitation and explain how you are addressing them. This goes back to my point about making the job of the reviewer easier.

– Weaker proposals are generally discussed less in a panel because there isnʻt much reason to have the panel spend a lot of time when they are already unanimous on their decision. Polarized proposals tend to get more discussion time. Basically so that NSF can get some “consensus”. If they have a proposal with 2 Excellents and 3 Fairs, and the panel recommends it for funding then the Program manager has to do ADDITIONAL work to justify that.

from George Hazelrigg (NSF program director for 18 years):

http://www.cs.rpi.edu/~trink/HazelriggWinningResearchProposal.pdf

from Dan Suthers:

Once in the 1990’s as a young researcher I stopped by NSF while in Arlington to talk to a PM and the person I was looking for was not there. I ended up in the office of someone else who gave me a succinct outline for a proposal that stuck with me. (This is not exactly what he said — it is in my words.)

* Vision: Wouldn’t it be great if we were here (knew this, could do this)
* State of knowledge/art: Currently we are here (show you know the lit)
* Plan: This is how we can reduce the gap in a specific way
* Right Team: This is why we are the people to do it (and what we need from NSF to pull it off).

Of course other outlines are possible.

From Depeng Li:

I just served a NSF panel at Arlington VA and then fly back our city from the cold. In the panel, I find that there are some issues which could hurt the chance of the proposal to be rated as high competitive/competitive.

(1) Just provide a wish list and the tools that PIs are going to use in the proposed research. But PIs do not explain how the tool/method will be used so that the goal can be achieved. Actually, even a simple explanation helps. Otherwise, it is hard for reviewers to virtually build it by themselves.

(2) Motivations are not clearly described or the case used to motivate the proposal is not so real. Therefore, the panel cannot be persuaded.

(3) The three thrusts cannot form a coherent whole picture. Thus, it looks like that they belong to different proposals.

(4) Blank statement: sometime, proposals just claim that novel science is achieved in the proposed research but there is no detailed support.

(5) Overstatement: PIs claim something will be achieved but does not give sufficient details OR the justification does not come together.

(6) PI should be qualified for their proposed research work. It should be verified based on their previous research records. It helps if what have been done is listed. It will be much more convincing if the preliminary work is published on referred journal/conference and the preliminary data/results are carefully analyzed.

(7) No measurement plan. It will be convincing if the detailed measurement plan is specified with detailed steps.

(8) Each thrust should be in charged of by a PI who is qualified enough to achieve it. It means that the PI should have already achieved lots of similar research / preliminary work so that the panel thinks PIs are capable of.
[/av_toggle]
[/av_toggle_container]