Code Monkey home page Code Monkey logo

about-us's People

Contributors

apcraig avatar duvivier avatar eclare108213 avatar phil-blain avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

about-us's Issues

Highlights

create a "recent highlights" page that includes links to news articles, agency brochures, AGU/EGU abstracts, etc

Track community development and validation activities

As discussed in our November 2020 team meeting, I've created a wiki page to track major development and validation efforts, in the About-Us repository because it includes both CICE and Icepack. This was originally suggested by @proteanplanet for MOSAiC simulations, and I've generalized the idea. I do not intend for this to include bug fixes, small parameterization upgrades, and maintenance work that we do as part of the Consortium, but rather large efforts that are funded above and beyond our Consortium tasks -- things like the landfast ice and FSD projects, which I've included in the table as examples and for completeness. When our sponsors wonder what they are getting for their Consortium investment, I hope that this information will help answer that question.

This is a draft, and I welcome suggestions for doing this other ways. Please comment on it in this issue, and forgive me for forgetting something that ought to be here -- we can add it (like maybe the NUOPC caps?). Once we're happy with the basic outline/info, I'll ask the external contacts already listed to update their information. Then we can create a forum thread (if you all think that's a reasonable idea) and I can send email to the cice-users mailing list asking for input.

Add a Code of Conduct to the repository

A Code of Conduct (COC) for expected behaviors between people on projects is a github best practice, and a best practice in general for communities. NSF has asked UCAR to develop one that would be used for projects with strong management/participation from UCAR employees.
The importance of a COC is to establish respectful behavior that maintains diversity and inclusion on the project as well as increase productivity. People are more productive when they are respected and valued on the project.

The UCAR COC is here...

https://www.ucar.edu/who-we-are/ethics-integrity/codes-conduct/contributors

The DOI for it that points to above is here...

https://doi.org/10.5065/6w2c-a132

There is also a markdown version of it on the above as that is most likely what would be adopted. The two changes that would be made would be to change the name of the project and the date it was adopted.

Since, CICE-Consortium is inherently a project of many different institutions and entities, it may not make sense to just adopt the UCAR version. However, note that most of the content would likely be what would be desired to be adopted. The one thing that the UCAR version adds is about reporting bad behavior to UCAR entities such as Human Resources, Office of Diversity and Inclusion, and Ethics and Legal. This obviously applies to UCAR employees, but I want to note that this same reporting can also be done for non-UCAR employees, and there are options for what can be done in that case.

For CICE-Consortium you may want to expand the reporting part to include more reporting options for other institutions.

I'm not a CICE-Consortium developer, but I can be involved in discussions on this issue and help with your understanding of the reasons for adopting a COC.

CICE User's Workshop

To the main developers in the @CICE-Consortium/devteam, we would like your input on a User's Workshop. Let us know which dates work best for you and thoughts on the agenda and format.

Dave and Alek

Dear CICE user community,

The CICE Consortium is looking to organize a virtual CICE User Workshop this spring (March/April 2022). The aim of the workshop is to share key updates and future plans from the Consortium and to solicit updates and feedback from the wider CICE user community. We expect the workshop will span two half days (to hopefully increase international participation) and consist of small talks and discussion sessions.

We are emailing to solicit information from you all about your possible involvement and availability. If so we would appreciate it if you could reply to Alek Petty ([email protected]) with the following information:

Your preferred date/s from the following:
(a) March 15-16 (10am-2pm EST)
(b) March 17-18 (10am-2pm EST)
(c) March 22-23 (10am-2pm EST)
(d) March 23-24 (10am-2pm EST)
(e) April 12-13 (10am-2pm EST)
(e) April 14-15 (10am-2pm EST)
Your desire to give a short update presentation (probably capped at 10 minutes)
Any feedback on your inability to attend
We look forward to hearing from you.

Regards,

Alek, Dave & Elizabeth

C012 session at the Fall 2022 AGU meeting

Hi everyone,

Just wanted to make you CICE folks aware of the following AGU session "C012 - Community Tools and Products for Cryosphere Discovery and Application". They are keen to have a bigger sea ice representation and obviously CICE/ICEPACK are some of the best examples of open sea ice community tools out there!

Not sure I will be able to make the next CICE meeting as I will be on vacation, but I could help put together a poster if anyone is interested. I probably wont be attending in person this year. Full session details below for those interested.

Cheers,

Alek

C012 - Community Tools and Products for Cryosphere Discovery and Application
The cryosphere research community strives to characterize, understand, and predict complex environments that are undergoing rapid change. These rapid changes have societal impacts - from glacial hazards to permafrost thaw to sea ice navigability to water security. Due to their societal importance, analysis of these rapid changes must keep up with scientist and decision maker needs. To enhance collaboration, analysis efficiency, and increase discovery by different stakeholders, many in the cryosphere science community use, have built or are building valuable community tools and datasets. These resources help support accessible science and technology across applications and international boundaries. These exciting advances are being made to better connect our community with a vast body of open source software expertise, while open licensing enables serendipitous knowledge exchange within the research sector and more broadly. Open source tools and datasets are most useful when the community knows how to find and apply them, highlighting the need for functional metadata, open documentation and community discussion for these resources. This session highlights open source and open access research tools, collaborative data products aligning with FAIR data principles, and examples and demonstration of their successful application.

Primary Convener
Tyler C Sutterley
Applied Physics Laboratory University of Washington
Conveners
Twila A Moon
University of Colorado at Boulder
Elizabeth Ultee
Middlebury College
Alek Petty
NASA Goddard Space Flight Center
Earth System Science Interdisciplinary Center

Consortium Documentation Organization

I am creating this issue to allow us to review our current documentation organization and discuss potential changes. I have attached a pdf that attempts to show our current organization both in outline form and via some sort of primitive dependency graph. The outline syntax attempts to identify unique pages and links (->). An "S" at the front means it's on the sidebar. The dependency graphs are generated for the CICE (page 2), Icepack (page 3), and About-Us (page 4) repos as well as all together (page 5). The arrows point from the document to the link and should be darker at the source to help highlight the direction of the dependence. Page 6 proposes some updates to the About-Us organization and page 7 shows the dependency graph of that. To help make it easier to see, page 8 and 9 show the About-Us dependency graph for the current and proposed About-Us structure with links from the Resource Index page removed (because it points to everything).

Attachment is Consortium-Doc-Org.pdf

My proposal addresses a number of different issues that I hope will make the documentation easier to navigate and understand as well as maintain. I am initially proposing some changes to About-Us organization, but what I propose also covers some other issues like clearly identifying format, number, and reuse of documents in multiple repos (like Copyright/License/COC)

I think the main points I've highlighted on page 6 are

  • Try to simplify organization to make it easier to find things and maintain
  • Avoid links into sections of a document
  • Get rid of documentation in About-Us repo and move to wiki
  • Less circular logic in linking. Create a clearer hierarchy of documents with better flow. This does not need to be "perfect", but I think it could be better than what we have.
  • Should we combine news and news archive?
  • Move FAQ to cesm forums
  • Manage links to external sites better so there are fewer links to maintain. For instance, create a document that links to cesm forum and have other documents point to the document vs have all documents point to cesm forums directly. This is much easier to maintain (both the link and description of cesm forum exists in only one place).
  • Have sidebar links and document names agree better to reinforce a “single” name
  • Group together documents and topics where possible.
  • Organize Governance documents better both in terms of stuff that needs to be in each repo and stuff that can be centralized
  • Decide what documents needs to exist in all repos and/or on wikis and decide format, recommend text or .md to make things easier to change
    • License?
    • COC?
    • ?
  • Identfy and reduce number of current copyright statements. Can we point and/or reuse? Can we have single format? Can we implement a tool that quickly updates all? Currently, they exist in
    • License in each repo
    • icepack/icepack_inlc.F90
    • icepack/icedrv_main.F90
    • icepack + cice doc conf.py
    • icepack + cice doc copyright.rst
    • cice every driver in either CICE.F90 or CICE_copyright.txt (inconsistent)

I'm not suggesting all of this is necessary or that it's comprehensive. Anyway, I thought this might be useful to do at this point since our documentation and process is maturing, and it might be good to try to review what we have.

copyright update

We need to update the year from 2019 to 2020 everywhere it appears in a copyright statement. Is there a way to do this all at once using a slick script? @apcraig I'd appreciate it if you'd at least locate all of them. I would like to make sure that we have them in all the places needed, e.g. in the Icepack interface modules/routines. I'm labeling this as "bug" because we haven't made the regular labels in this repository and it's high priority -- this needs to be done before the next release.

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.