Code Monkey home page Code Monkey logo

opm-meeting20's Introduction

Community Planning for OPM Meeting 2020

This repository does not and will not host. It will only be used to organize the Open Porous Media (OPM) Meeting 2020, taking plan February 4-5, 2020 in Eichstätt, Bavaria, Germany. For location, travel, schedule, and registration see the registration page.

Proposing talks

Topics of talks should be connected to OPM, e.g. development, usage of it by you and your institution, how project/library could improve or contribute to OPM's success, what you would further expect from OPM, experiences as a user and/or developer. They should be flexible in length as we cannot foresee how many there will be in the end and do not expect to decline talks unless they are inappropriate, i.e. not related to OPM at all. In previous meetings talks got slots of half an hour and this is unlikely to change drastically as of January 14.

Whe you register, you can already tell us if you want to give a talk at the meeting. You will find the list of proposed talks in the wiki. If you did not do this and want to give one then please add yourself to the table in the wiki or send an message pr Email to Markus Blatt.

Unconference and Discussion / Hacking groups

While talks are nice and fine, the main reason for the meeting should be to discuss stuff, and work together, eg. on problems and solutions. You might remember that special conference that really made a difference to your work, don't you? What was the best part again? Chances are it were not exactly the talks but the rest: the informal discussions (in small group), the chat about topic X with another attendee, etc.

Hence, we want to make the second part of the meeting (at least the second day) only consist of these highly productive parts of a conference. But here we need your help. Tell us what you want to discuss, what you want to work on. This is usually called an unconference.

We will misuse this repository's issue tracker for proposing topics/groups in advance. But you can still propose them onsite at the meeting. Please use the issue tracker to propose a topic with a short description. Please tag it with "user" (if it is of interest to users), "developers" (if it is of interest to developers), "discussion" (if this is mainly discussion), "hacking" (if it includes hacking) or add your own label. BTW it makes a lot of sense if the proposer is attending the meeting or finds an attendee that fills the spot as moderator of the group if he or she is not attending.

Other attendees can of course leave their comments in the issue tracker, but remember that the unconference will happen face to face at the meeting and comments might be disregarded. It is more important to use github's reactions by making a ":+1" comment if it is interesting to you. This will allow us to sort the proposals a bit before the conference.

There is a great chance that we might be able to attack all proposed topics/groups. As of January 14, 2020 the time available seems ample and the number of proposed talks is still very tractable.

If you do not have a github account then just send a mail to Markus Blatt.

opm-meeting20's People

Contributors

atgeirr avatar blattms avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opm-meeting20's Issues

Best practices as a release manager

We have done quite some releases with different managers by now. What was good, what was bad.
Can we come up with a guideline for future release managers?

Model for: Error messages and warnings

Configure behavior with errors and warnings reaching the user. Currently the action when a problem is encountered is typically handled at locally at the problematic site, and to a large extent the final outcome depends on the good taste of the currently active developer. Possible actions include:

  • Throw an exception
  • Print a message to `std:err.
  • Add a log message
  • Ignore it ....

The problems with this include:

  1. It is inconsistent for the user.
  2. It is impossible / difficult for the user to configure the behavior.

I suggest creating a model for configurable error handling inspired by the ParseContext class in opm-common[1] which can be used throughout the simulator to query error behavior. In addition to the existing actions currently managed by the ParseContext we should - at least - have some counter based system which will promote a warning to an error and things like that. The code will need to interact closely with the log system and the messagelimiter.

The obvious disadvantage of this is that a myriad of functions will need to get an additional ErrorConfig object passed as a new argument.

[1]: Actually I would suggest renaming the ParseContextclass to e.g. ErrorConfig and then extend that.

Communication about code and new features

Is our communication strategy optimal? Maybe we should hire someone to assist us?

Some thoughs/suggestions about comminuication:

Roadmap / plans for the year:
Large scale projects should be published on the webpage; it should be simple to go to a webpage and find for 2020:

Feature Responsible Complete by
Feature1: This feature will allow flow to ... Steve Jobs ...?
Feature2: Cool feature 2 Bill Gates Q4

PR's and issues

  • I think it is a good principle to announce large features as issues in advance.

  • Small PR's improve communication

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.