Skip to content

essentials.md

Latest commit

 

History

History
205 lines (137 loc) · 10.4 KB

essentials.md

File metadata and controls

205 lines (137 loc) · 10.4 KB
Raw

WORKING GROUP ESSENTIALS



WELCOME

Welcome to our working group!

If you are new to this project, we strongly encourage you to familiarize yourself with the basic content of this page. This will help you to jump right into the conversations we are having during our weekly meetings. Gaining familiarity with the history of this project will avoid confusions and waste of time (for you and the rest of the team).

Keep the following URLs handy as reference for all the work we have been producing under this project.


MEETINGS AND COMMS ETIQUETTE

When participating in our meetings, please:

  • Arrive on time.
  • Turn your camera on (seriously, turn your cammera on).
  • Keep your microphone off (unless you are speaking, of course).

If you want present your progress, please:

  • Include your name in the Spring 2026 schedule
  • If relevant, include the URLs for the resources you want to discuss.
  • Let's try to respect the order of cotributors listed in the agenda.
  • Please be mindful of the time, so keep your contributions on point.

In terms of communications, please:

  • Keep an eye on the quick communications channel used in your team (Slack, Teams, etc.)
  • Please respond quickly and effectively
  • If you are CCed in an email, please send your response CCing all the people included in the first email (unless you want to communicate something personal). This keeps everyone in the knowing and facilitates to communication efficiency.
  • Try to minimize email communications and when doing so, please keep them brief and on point.

ConfliBERT BASIC DEVELOPMENTS

Please read the papers presenting the ConfliBERT family models in English, Spanish, and Arabic. Pay particular attention to the information sources and volume of corpus used for pre-training ConfliBERT in each language. You also want to identify the different versions of ConfliBERT (continual/from scratch, cased/uncased) available in each language. Also pay attention to the databases and specific tasks used in the downstream applications in each paper.


alt text

Seriously, please read the three papers listed above. Then you can keep going.


GOT A PAPER IDEA??

Awesome! We love new ideas and really like working with proactive collaborators. Before you get started with your own work, please take a look at our previous work in the project's main website.

Here you will see our work around the following topics:

  • Extractive and Generative AI
  • Active Learning
  • Machine Translation
  • Zero Shot
  • Event data
  • Applications on conflict research

So, before you get started, please get yourself familiar with the work that we have been doing. That will help you get quickly on top of your game.


LEADING A RESEARCH PAPER

If you are leading a research paper, we encourage you to consider the following elements:

  • Discuss with one of the PIs the alignment of your paper idea with the overall objectives of the grant.
    • Prepare a 4-slides presentation responding to: what is the problem? what is the solution? what is the impact? what do you need?
    • Please be open to feedback.
  • Get your team together.
    • Make sure you have the right collaborators and resources (data, computing, etc.) that you need for the paper.
    • Please be a good citizen. Show up, respond to emails, do your part, be kind.
    • As a convention in this group, the PIs are included as coauthors toward the end of the list.
  • Identify a target conference or journal and mark the submission date.
    • Make sure your work is in line with the conference or journal objectives.
    • Create an Overleaf document and GitHub repo and share them with your collaborators.
  • Manage and report your progress.
    • Use a project management tool (Trello, Monday, Asana, etc.) to schedule your work and track your progress.
    • Meet regularly with your working group to report progress.
    • Be ready to present your progress in our general meeting.
      • Mark your presentation in our meeting schedule.
      • Include a link to your slides in our meeting schedule.
  • Share the final draft of your paper with the PIs at least one week before the submission deadline.

DOCUMENT YOUR WORK

We have a big collaborative team that often involves several members working on the same project. Also, we often use data, results, or outputs of some papers as inputs for new papers. So, it is super important for you to document everything that you do.

In this project, we abide by the FAIR principles, which stands for:

  • Findability
  • Accessibility
  • Interoperability
  • Reuse of digital assets

The overall objective is that all your data, scripts, and results should be easily accessible and replicable by anyone. Here, "anyone" means any member of our team, but also any external user who may not have any idea about the project or even advanced computer science skills. So, please make sure you structure your work flow, organize your data, write your scripts, and specific routines and commands in a way that anyone can follow your work.

Here are a few basic guidelines to keep in mind:

  1. Your data and scripts are not yours.
    • Yes, you are the one doing all the work, but all the data and script should be tailored to a general public audience.
    • You certainly have your own working style and speak python or R as your native language. But not everyone is familiar with your style or has the same level of technical skills as you do. So, please make sure you document your work in a way that anyone can follow you.
    • The best practice for making your work FAIR is to intentionally start your work with a FAIR mindset since the begining. Avoid falling into the trap of "I will write this code very quickly, and then I will go back and edit for streamlining purposes". No, that is not an efficient use of time and it increases the chances of you not doing it.
  2. Document everything.
    • Documenting your work is your responsibility. Inadequate documentation leads to waste of time, duplicated efforts, or even data loss.
    • Organize your folders and subfolders in an intuitive and hierarchical way.
    • Please use headers and subheaders in your scripts to clearly structure and organize your work.
    • Make excessive use of comments to describe procedures and steps in your code. Ideally, you should document this for each single command.
    • This takes a concious documentation effort in structuring and conducting your work at every step. It will be hard at the beginning, but eventually it should flow naturally.
  3. Use snake_case convention.
    • Try to use the snake_case for file nomenclature, variable names, and for developing your script.
    • Avoid at all costs the use of special characters for file or variable names (e.g. :, *, #, !, etc.).
  4. Use prefixes for sequential steps.
    • Try to use numeric prefixes in your folder and file names (e.g. 1_filename.txt) to indicate steps or scripts that should be run in sequential order.
  5. Use sufixes for version control.
    • Always use numeric sufixes for version control (e.g. 1_filename_v1.txt). In this way, the v sufix can help you track the evolution of your files.
    • You can also create an old folder to archive previous versions of your code to prevent clutering your working space without deleting old files.
  6. Always have a README file.
    • Whether you are working locally, a folder in the AHP, or on GitHub, please write a README file. This should serve as your first guideline for your project.
    • Write as many README files as folders and subfolders in your project.
  7. Ensure replicability.
    • Make sure anyone can run your entire code to replicate all your results without your supervision. Your folders, scripts, and data should be self-explanatory. Avoid the "well, it runs in my computer" excuse.
  8. Keep your work updated.
    • Most likely, you will be working in a collaborative space (e.g. GitHub, Delta, Arizona HPC). If you are also conducting part of your work locally, please make sure that the shared folder contains the latest update of your work.
    • Make sure all those who need access to your data and scripts in the shared space have access to it. This does not mean that the space has to be public (yet), just make sure that all your team members can access the latest version of your files.
    • We tend to work at a very quick pace. So, make sure all your files are updated in the shared space.

WORKING ON HPC

USIGN THE UA HPC

The University of Arizona (UA) High Performance Computing (HPC) space gets completely wiped out every year at some point during the summer. If you are working on the UA HPC you are responsible for backing up all your data before everything is deleted.

Please take this seriously and schedule your data backup with enough anticipation to prevent catastrophic data loss. Do not underestimate the time it takes to backup your data.


USING ACCESS / DELTA Resources

  • ACCESS Signup is here
  • Ask Dr. Brandt or Dr. Alsarra to then add you to our allocation group
  • Talk with someone who has already used these HPC resourses so you learn what to (not) do.

LOCAL ONBOARDING STEPS

  1. Add participant to local Teams / Slack / messaging group
  2. Add participant to github.com/eventdata
  3. Add participant to sub-group meetings
  4. Direct participant to this page!