Add CONTRIBUTING, update README

[phil-blain]

PR checklist

• Short (1 sentence) summary of your PR:
  Add a Contribution guide (CONTRIBUTING.md) and update the README to make it more welcoming.
• Developer(s):
  Philippe Blain
• Suggest PR reviewers from list in the column to the right.
  I'll ping everyone on this one:
  @eclare108213 @apcraig @duvivier @dabail10 @JFLemieux73 @proteanplanet @CICE-Consortium/devteam @mattdturner @rgrumbine @rallard77 @TillRasmussen
• Please copy the PR test results link or provide a summary of testing completed below.
  No tests.
• How much do the PR code changes differ from the unmodified code?
  • bit for bit
  • different at roundoff level
  • more substantial
• Does this PR create or have dependencies on Icepack or any other models?
  • Yes
  • No
• Does this PR add any new test cases?
  • Yes
  • No
• Is the documentation being updated? ("Documentation" includes information on the wiki or in the .rst files from doc/source/, which are used to create the online technical docs at https://readthedocs.org/projects/cice-consortium-cice/. A test build of the technical docs will be performed as part of the PR testing.)
  • Yes
  • No, does the documentation need to be updated at a later time?
    • Yes
    • No
• Please provide any additional information or relevant details below:

This would close #384.

You can see the formatted documents over at my fork:
CONTRIBUTING.md
README.md

I would welcome any feedback: wording, formatting, section placements, etc.

I think the wording I chose makes it clear that support requests and feature requests should go to the bulletin board, but genuine bugs should be reported using GitHub issues. I think that is the consensus that was reached during our last call. If we feel like we should outright tell people to not open issues and always open a thread on the bulletin board instead, I'll update the PR.

I think our README looks a lot better and is more welcoming with these changes.

Please @-mention others I might have forgotten (especially new Consortium members as this is mostly targeted to them!)

P.S.: once consensus is reached on the content and wording I'll do a similar PR for Icepack.

[eclare108213]

Thank you, @phil-blain. This is very nice -- I agree it is a friendlier introduction than the current README. I would like others to weigh in on these files, especially the number and type of links that are included. We have worked hard to consolidate links into the resources wiki page to reduce maintenance, e.g. when the bulletin board location suddenly changes, and this repeats some of those.

I would like to suggest that we use the term "forum" instead of "bulletin board", everywhere it appears. The latter sounds like it's just for announcements, while "forum" invites discussion.

Re CONTRIBUTING:
Is this the minimum information and pointers needed to get someone started? Another potential option could be, where it makes sense, to not have an in-line, active link, but put a link to the resources wiki page near the top of CONTRIBUTING.md and send people there for more info. Some of these links are new/different from what we already have, and could stay.

I would prefer that issues be reserved for Consortium member use -- have users go first to the forum, and we (or they, with our permission) can create an issue after we've had a chance to review the problem. Users often classify things as bugs when the code doesn't act the way they expect it too, not realizing that we've intentionally made the code act that way. Your suggestions for what they should do when reporting an issue are still apropos. I would probably reword the porting bullet to emphasize that they should probably involve their IT people first!

Re README
I've tried not to emphasize any Consortium institution in the first-look info, including LANL, which is why that first statement isn't in the README now. A replacement statement could be

CICE is a computationally efficient model for simulating the growth, melting, and movement of polar sea ice. Designed as one component of coupled atmosphere-ocean-land-ice global climate models, today’s CICE model is the outcome of more than two decades of community collaboration in building a sea ice model suitable for multiple uses including process studies, operational forecasting, and climate simulation.

I think it's best to keep the 'getting started' instructions just in the docs. You have a pointer to them already under 'getting help', so I recommend removing the 'getting started' section entirely. By showing users the docs early on, we might head off some unnecessary questions.

[apcraig]

I do think some of the content is quite helpful, but I also agree that we should not be duplicating links (or even content) in multiple places. In fact, I think I've been the most proactive in that regard. My preference would be that the only place we have links in on the resource page and all other places point ONLY to the resource page. In the same way, documentation (like how to download the code or setup a case) would exist only in one place. That way, we only have one thing to maintain when things change.

I think some of this content could be moved to the resource page which would almost certainly make it better. Some of the info here could be dropped into the other documents as well. I totally understand why it's appealing to do what's been done here, but I think it creates more work overall in some ways.

Again, my preference is that everything points to the resource page. That resource page should be well organized and point to various documents and other things in a friendly and clear way. And those documents on the resource page should overlap as little as possible (again to compartmentalize content and minimize redundancy).

[eclare108213]

To be clear @apcraig, are you suggesting to keep the basic outline of CONTRIBUTING but move the details elsewhere (especially the resources page)? I think that could still be helpful. @phil-blain where does CONTRIBUTING.md appear in GitHub? Is it something that will be staring people in the face as soon as they open a repository page?

[apcraig]

I guess what I'm suggesting is that both in the README and the CONTRIBUTING page that more or less the only link that exists (if possible) is to the CICE Resource Page. We could then add/update the content on the CICE Resource Page (or other documents) based upon what @phil-blain has done here. In other words, I propose both look something like

This is the CICE README/CONTRIBUTING page. For more information, see https://github.com/CICE-Consortium/About-Us/wiki/Resource-Index which contains information about how to download and run the code, pointers to input data, how to get help, and many other things.

But written with a little more fluff and pizazz. If we wanted there to be quite a bit more information, that's OK. I would just avoid having a bunch of links or redundant content if possible. Again, that's just my proposal/preference for organizing our documentation. The "half dozen" changes that were required to address the bulletin board change is a good example about why I think having everything centralized provides some benefits to us. And if the resource page and our documentation is well organized, it should be more than adequate for users.

[apcraig]

One other thing, I would remove the new content in the PULL_REQUEST_TEMPLATE. It really doesn't much matter whether the "check boxes" are checked or not as far as I'm concerned. It's sort of an interesting feature, but not an important feature. In this case, I think it's better to leave out those details than add more text. In fact, if you do all the things requested by the template, you still haven't checked all the boxes. And the only place the info shows up that I can find is in the Pull Request list where it says something like (10 out of 16) in regards to the check boxes. Again, not particularly useful to worry about the check boxes overall in terms of our process. The main point is to do and fill out the template.

[phil-blain]

Regarding the pull request template:
the new content is in HTML comments so it will not appear once the PR is created... I think our PRs looks more professionnal when the check boxes are correctly checked :P

but I can drop that commit if we feel it's not an issue.

[apcraig]

I just want to ping this thread. I think we should try to finish this up. I think the main outstanding question is whether we want the README and CONTRIBUTING files to have so many details. I have argued the README and CONTRIBUTING pages should point to the resource page for more details and we should not duplicate the documentation as that just creates additional maintenance work. I think there are also other benefits if users just leverage the resource page as their go-to Consortium documentation/information starting point.

[eclare108213]

I agree that we should avoid duplication and link mainly (maybe only) to the resources page. However that page does not provide a lot of guidance for someone approaching the Consortium for the first time. Maybe the 'contributing' page can provide some textual direction without links that need to be maintained. For example, we can say that the place to find information about dealing with the icepack submodule is in the git workflow document (which is linked from the resources page), and the place to find information about testing requirements for contributing new code, and information about the tests themselves, is in so-and-so section of the documentation (also linked from the resources page). I don't think we should clutter up the resources page with a lot of extra, descriptive text. This approach might 'feel' a little friendlier to users without being maintenance-heavy for us. We'd still want to review it every once in a while. I think the tutorial will provide us with some feedback on the kinds of guidance that new (and experienced) users might need most.

[apcraig]

I think it's great to have some text to provide an overview. I even don't mind having a few links (like to the resource page, bulletin board, and something else, for instance). But I think we should consciously avoid too much redundancy. I also think some of the updates in the README and CONTRIBUTING documents as they currently stand could/should be migrated to the resource page and/or other documents. The information is nicely presented. I think we should be constantly improving the resource page. I feel it's one of the most critical pages in the Consortium project.

[eclare108213]

I'll be working on Consortium stuff for the tutorial this afternoon, traveling back to NM, and will try to take a stab at this text.

[phil-blain]

I can also update this PR once a consensus has been reached...

@eclare108213 to answer your question:

@phil-blain where does CONTRIBUTING.md appear in GitHub? Is it something that will be staring people in the face as soon as they open a repository page?

When GitHub users go to open their first issue or pull request in a project, GitHub shows these banners:
For issues:

For PRs:

In both cases, the "contributing guidelines" link to CONTRIBUTING.md.

[eclare108213]

Can we control the text of those banners? e

[phil-blain]

No.

[phil-blain]

I would like to suggest that we use the term "forum" instead of "bulletin board", everywhere it appears. The latter sounds like it's just for announcements, while "forum" invites discussion.

fixed

Re README
I've tried not to emphasize any Consortium institution in the first-look info, including LANL, which is why that first statement isn't in the README now.

fixed

[phil-blain]

@apcraig

I would remove the new content in the PULL_REQUEST_TEMPLATE.

done

[apcraig]

That looks good to me. Thanks.

[eclare108213]

I added a new Contributing page to the About-Us wiki but did not create any links to it except this one. I further reduced the internal links and took out some but not all of the external links. Please take a look and make suggestions in this PR conversation.

Here are my suggestions for other pages:

CONTRIBUTING.md

Welcome to the CICE Consortium! There are many ways to contribute, and we appreciate your efforts. For an introductory tour, head over to our [Contribution guide] and take a look at the [Resources page], our go-to index with links to code, documentation, testing information, guidelines, and more.

Resource index

• Change ‘bulletin board’ to ‘forum’ (do this on other pages where it appears)
• Under Model Testing, add a link ‘See also the [Information for Developers] below.’
• Currently, ‘Contributing to model development’ links to the FAQ. Instead, this should link to the new 'Contributing' wiki page and the FAQ should also point to the new page.

FAQ

• Link to 'Contributing' wiki page
• The testing criteria on the FAQ should be removed and instead linked to the Required Testing section of the Software Development Practices guide.
• (Note to self: update the institutional member list on the FAQ, or remove it)

Top of README (include links to CICE-svn-trunk and at the bottom as before, but use ‘forum’ instead of ‘bulletin board’):

CICE is a computationally efficient model for simulating the growth, melting, and movement of polar sea ice. Designed as one component of coupled atmosphere-ocean-land-ice global climate models, today’s CICE model is the outcome of more than two decades of community collaboration in building a sea ice model suitable for multiple uses that include process studies, operational forecasting, and climate simulation.

This repository contains the files and code needed to run the CICE sea ice numerical model starting with version 6. CICE is maintained by the CICE Consortium. Versions prior to v6 are found in the CICE-svn-trunk repository.

CICE consists of a top level driver and dynamical core plus the Icepack column physics code, which is included in CICE as a git submodule. Because Icepack is a submodule of CICE, Icepack and CICE development are handled independently with respect to the github repositories even though development and testing may be done together.

If you need help getting started using the model after reviewing the model documentation, the first point of contact with the CICE Consortium is the Consortium Community Forum (linked below). This forum is monitored by Consortium members and open to the whole community. Please do not use our issue tracker for general support questions.

If you expect to make any changes to the code, we recommend that you first fork both the CICE and Icepack repositories. In order to incorporate your developments into the Consortium code it is imperative you follow the guidance for Pull Requests and testing. Head over to our Contribution Guide (linked from the Resource Index below) to learn more about how you can help improve CICE.

[apcraig]

I like the new contributing page. I would suggest a few changes. I would try to avoid the "About-Us" references/links. I view the About-Us as sort of a potential landing page and a place where we keep a lot of our documentation. But I don't think of it as a place that should be linked to or really mentioned. I don't think there is anything on the About-Us page that is not on the Resource Page. And I think we should try to avoid mentioning anything related to the organization of our documentation, so the fact that a bunch of the documentation is on the About Us wiki vs the Icepack wiki or CICE wiki or even external should not be exposed. So, I would change

A detailed overview of our [Git workflow], including a Git primer for less experienced users, is found on the [About-Us] wiki.

to

We provide a detailed overview of our [Git workflow] including a Git primer for less experienced users.

I would change

We even have documentation about the documentation: the [About-Us wiki] has information about syntax, building the documentation locally, and Frequently Asked Questions.

to

We even have documentation about the documentation: the [Documentation Workflow Document] has information about syntax, building the documentation locally, and Frequently Asked Questions.

I would not mention the squashed merge at the end. And I don't fully understand what the final sentence/link is contributing. (A helpful hint: Use [GitHub Flavored Markdown] appropriately.)

Finally, I would move this

The column portion of the model, Icepack, is included in CICE as a Git submodule. Submodules are a more advanced feature of Git that even experienced Git users might not have encountered, and we recommend getting comfortable with the concept. Some reading materials, in increasing level of complexity:

The Submodules section of the Git Tower tutorial (introductory)
The Submodules chapter of the Pro Git book (in depth)
The official Git documentation: gitsubmodules, git-submodule, gitmodules (reference)

to the git workflow document under submodules. I think noting submodules are important is good, but I think pointing to the git workflow document is adequate at this level. If we include these links in the submodule section of the workflow document, I think that would be best.

[eclare108213]

I like these suggestions @apcraig and have made the changes to the 'contributing' wiki page, including moving the submodule links to the git workflow doc. I have not made the other changes that I suggested above, waiting for others' opinions.

[phil-blain]

@eclare108213 : I think having the Contributing page in the About-Us wiki is a good compromise. It's true that it causes less administrative burden to update and less duplication since CICE and Icepack can both link to it instead of duplicating content.
To give more visibility to this page, I would link to it from a few places:

• the home page of the About-Us wiki https://github.com/CICE-Consortium/About-Us/wiki
• the side bar of the About-Us wiki (super important to make it easy to find)
• CONTRIBUTING.md in CICE and Icepack
• probably also README.md in CICE and Icepack

I'm also ok with moving the submodule resources to the Git Workflow page.

---

Regarding the comments by @apcraig :

I would try to avoid the "About-Us" references/links.

The reason why I explicitly mentioned "the About-Us wiki" is that when I started with the Consortium, I was always confused by how the documentation is organized. For example, I would try to find the "Git workflow Guidance" page often, first by looking in the CICE wiki, not finding it, then clicking Resource Index, looking at the sidebar, still not finding it, then scrolling down and finally finding the link.
Or I would go to the About-Us repo, and then not find it either.
So that is why I think it's good to name things, then people might remember more easily where they are.

I would not mention the squashed merge at the end.

For some contributors that are used to make atomic, self-contained commits, and write really detailed commit messages, it can be quite disconcerting for their pull requests to be integrated using this procedure, because all the work they did in splitting their work into separate commits is discarded. So I think we should at least warn these users that that is the procedure that is going to be used.

And I don't fully understand what the final sentence/link is contributing. (A helpful hint: Use [GitHub Flavored Markdown] appropriately.)

I agree; I had added that sentence when I talked about opening issues. In the latest version of this branch, I instead link to the appropriate syntax page on xenodo when I talk about opening new forum threads.

---

@eclare108213 regarding your suggestions to the different files/pages:

CONTRIBUTING.md: maybe I'd copy the "Getting help" section in there, so that it may deter more people from creating issues (since they have less links to click to in order to learn that we prefer they open a thread in the Forum)

FAQ and Resource Index: I think these are good ideas.

README: I would link directly in the text to the Forum, as well as to the Contributing page on the About-Us wiki.

---

Also of note: I just noticed that the About-Us repo has a code of conduct https://github.com/CICE-Consortium/About-Us/blob/master/CodeOfConduct.md
That is super, and we should really link to that in the new Contributing page of the wiki.

[duvivier]

Sorry I'm late to the thread here. @phil-blain, thanks for heading this up. I didn't know about this feature and it will be good to follow the expected github format of repos.

I've read through the comments so far and here are my opinions:

• I like the more detailed descriptions throughout, but I am also concerned like @apcraig with how many links there are in here that will be challenging to keep track of. This was the whole purpose of creating the resource links page - to minimize how messy links can get.

• If we keep a more verbose contributing.md format, I think that we should then keep that version in the About-Us repo. Then the contributing.md files in CICE and Icepack could both point to the contributing.md in About-Us.

@phil-blain I also don't like how the pull request template check boxes don't match up with the numbering. But I don't know how to fix that given that we don't have a linear PR process since we can have, for example, both b4b and non requests. But that information seems essential to me in the PR template so we can adequately review it.

I should be online all tomorrow to get this settled before the tutorial if that's our timeframe before people all start looking at this.

[eclare108213]

We are converging on this issue and I think we need to finish it up today. Remaining questions are in @phil-blain s comments above. I'm generally okay with all of those suggestions, but I think the jury is still out on where and how often to link the various pages. I like the idea of just linking to the resources page in theory, but in practice I can see how that is non-intuitive to people approaching the Consortium for the first few times. I think we should go with the single contributing page in About-Us (without too many links within it), briefly link to it from CONTRIBUTING.md (and we can add the 'how to get help' section there, but I might not), and then link to the contributing wiki from the READMEs. I don't think a contributing link needs to be explicit in the side bar, but then again I also find it a little frustrating to look there and not find stuff. Maybe we can annotate the sidebar link to 'resources' to make it more obvious as the place to go?

[duvivier]

I'm answering Phil's questions directly from his last message. I think this can be done today pretty easily. @phil-blain , if I can help with any of these last items let me know.

@eclare108213 : I think having the Contributing page in the About-Us wiki is a good compromise. It's true that it causes less administrative burden to update and less duplication since CICE and Icepack can both link to it instead of duplicating content.
To give more visibility to this page, I would link to it from a few places:

• the home page of the About-Us wiki https://github.com/CICE-Consortium/About-Us/wiki
• the side bar of the About-Us wiki (super important to make it easy to find)
• CONTRIBUTING.md in CICE and Icepack
• probably also README.md in CICE and Icepack

I'm fully on board with this solution. Linking in all the places you list, @phil-blain , makes sense to me.

I'm also ok with moving the submodule resources to the Git Workflow page.

This sounds good to me.

Regarding the comments by @apcraig :

I would try to avoid the "About-Us" references/links.

The reason why I explicitly mentioned "the About-Us wiki" is that when I started with the Consortium, I was always confused by how the documentation is organized. For example, I would try to find the "Git workflow Guidance" page often, first by looking in the CICE wiki, not finding it, then clicking Resource Index, looking at the sidebar, still not finding it, then scrolling down and finally finding the link.
Or I would go to the About-Us repo, and then not find it either.
So that is why I think it's good to name things, then people might remember more easily where they are.

I think this is good feedback that the process wasn't intuitive at first. If non team members aren't sure where to look and would usually look for a "contributing.md" file first for guidance, then we should create that with the info in it and links to other places (like the About-Us wiki). I think we can try this solution and we can always refine later, if necessary.

I would not mention the squashed merge at the end.

For some contributors that are used to make atomic, self-contained commits, and write really detailed commit messages, it can be quite disconcerting for their pull requests to be integrated using this procedure, because all the work they did in splitting their work into separate commits is discarded. So I think we should at least warn these users that that is the procedure that is going to be used.

I don't have as much familiarity with this, so I don't have an opinion to share.

And I don't fully understand what the final sentence/link is contributing. (A helpful hint: Use [GitHub Flavored Markdown] appropriately.)

I agree; I had added that sentence when I talked about opening issues. In the latest version of this branch, I instead link to the appropriate syntax page on xenodo when I talk about opening new forum threads.

@eclare108213 regarding your suggestions to the different files/pages:

CONTRIBUTING.md: maybe I'd copy the "Getting help" section in there, so that it may deter more people from creating issues (since they have less links to click to in order to learn that we prefer they open a thread in the Forum)

Sounds good to me.

FAQ and Resource Index: I think these are good ideas.

Yep, agree.

README: I would link directly in the text to the Forum, as well as to the Contributing page on the About-Us wiki.

Yep, agree.

Also of note: I just noticed that the About-Us repo has a code of conduct https://github.com/CICE-Consortium/About-Us/blob/master/CodeOfConduct.md
That is super, and we should really link to that in the new Contributing page of the wiki.
FYI, I'm opening the workshop and tutorial with this code of conduct info (as well as other logistics). This is an NCAR policy for meetings and I think just a good precedent to set.

Again, @phil-blain just let me know today what I can do to help. Reviewing, or helping with some of the PR's in other repos, etc. If you have it covered, then that's fine too. Thanks for heading this up! :)

[apcraig]

I'm happy to help push this forward today as well. I think we're converging and are reaching a reasonable compromise. As @duvivier says, we can always revise again in the future. It will be helpful to have this merged, then we can actually see what it looks like and continue to improve. Do we have a clear list of things that still needs to be done? I think it's at least

• update Contributing.md - simple paragraph pointing to contributing.md page as suggested by @eclare108213 above
• update README.md - reduce again as suggested by @eclare108213 above
• links to Contributing.md from several places
• move submodule resources to github workflow doc

On the squashed merge, I'm OK if others think it should be mentioned, but I don't think it should be one of the first things a user sees. Can we drop it into the github workflow doc as well.

I will update the github workflow doc now. I think for this PR, we mainly need to finalize the Contributing and README .md files. Those should be fairly straight-forward, largely pointing just to some primary links (resources, contributing, forum, etc). I think @eclare108213 has provided a reasonable version for both. By making them simple, they should be fairly static. We can then continue to improve all the surrounding documentation without needing to PR.

[phil-blain]

OK I'll update the README and CONTRIBUTING files soon.

[apcraig]

I have updated the git workflow document and confirm the submodule links are there. I also copied the squash-merge info into the PR section,

https://github.com/CICE-Consortium/About-Us/wiki/Git-Workflow-Guidance#submodules
https://github.com/CICE-Consortium/About-Us/wiki/Git-Workflow-Guidance#pull-request

I also added a link to the Contributing Page on the About-Us README and on the About-Us wiki sidebar

https://github.com/CICE-Consortium/About-Us
https://github.com/CICE-Consortium/About-Us/wiki

[phil-blain]

@eclare108213 @apcraig @duvivier :

I've pushed a commit reducing the length of CONTRIBUTING.md and instead linking to the About-Us wiki Contributing page, as discussed above.

This PR should be ready to merge, but we should make sure to do all the things we mentioned above that pertain to other repos (or check they have been done):

• change resource index as @eclare108213 wrote here Add CONTRIBUTING, update README #392 (comment)
• change FAQ @eclare108213 wrote here Add CONTRIBUTING, update README #392 (comment)
• do an icepack PR with README and CONTRIBUTING similar to the CICE ones - I can do that as soon as this one is approved EDIT PR is here: Add CONTRIBUTING, update README Icepack#293 I'll update it if needed.
• make sure all feedback from this PR has been incorporated in the Contributing page on the wiki
• link to the code of conduct from the Contributing on the wiki to give it more visibility ?

[duvivier]

@phil-blain I think this is looking really good. I have a number of little, minor changes. But overall I think it's very close to ready!

[duvivier]

@eclare108213 may want to weigh into how we refer to this model. My inclination would be to label this section "The CICE sea-ice model"

[eclare108213]

I agree it's more natural to just say "CICE sea-ice model"

[eclare108213]

I've left this as 'The CICE Consortium sea-ice model' for now, but we can change it if others think that sounds weird.

[apcraig]

@duvivier how are you viewing these pages "rendered"?

[duvivier]

@apcraig go directly to @phil-blain 's branch for this PR: https://github.com/phil-blain/CICE/blob/add-contributing/CONTRIBUTING.md

[apcraig]

@duvivier makes sense, thanks.

[apcraig]

* [x]  change resource index as @eclare108213 wrote here [#392 (comment)](https://github.com/CICE-Consortium/CICE/pull/392#issuecomment-578412376)

* [x]  change FAQ @eclare108213 wrote here [#392 (comment)](https://github.com/CICE-Consortium/CICE/pull/392#issuecomment-578412376)

* [ ]  do an icepack PR with README and CONTRIBUTING similar to the CICE ones - I can do that as soon as this one is approved **EDIT** PR is here: [CICE-Consortium/Icepack#293](https://github.com/CICE-Consortium/Icepack/pull/293) I'll update it if needed.

* [ ]  make sure all feedback from this PR has been incorporated in the Contributing page on the wiki

* [ ]  link to the code of conduct from the Contributing on the wiki to give it more visibility ?

I have checked off the first two boxes.

[apcraig]

(Note to self: update the institutional member list on the FAQ, or remove it)

As I have been advocating, I think we should document stuff in one place and then point to it as much as possible. I know this isn't always possible nor is it always the best approach, but it makes maintenance easier. At some point, maybe we should review our documentation and put together a little dependency/coverage diagram to help us recognize redundant documentation and/or unusual redirecting links in order to further clean this up. I'm happy to do that if others agree, but don't want to push this point farther than I should :)

[eclare108213]

I would remove the 'getting help' and 'contributing' headers from the README and remove the boldface formatting from the sentence about issues. Otherwise, I agree with all of the comments and suggestions by @duvivier and @apcraig. If no one else is able to work on this in the meantime, I'll try to finish it up later today.

[duvivier]

It doesn't look like this gone completed today, but we can discuss tomorrow at dinner if we want to finish it up before Tuesday.

[eclare108213]

I have checked the Contributing, Resource Index, About-Us and FAQ pages and further edited them as noted above. I did not add a link to the Contributing wiki page in the main About-Us wiki page, but I put the link in the side bar in a prominent place, and generally reorganized that side bar to emphasize the important stuff. I added a link to the code of conduct in the resources index and mentioned it in the Contributing wiki page without a direct link.

I believe that the only thing left to do is to update the Contributing.md and README.md files in this PR as suggested by @duvivier and @apcraig. Rather than cloning the wiki and pushing to @phil-blain's branch, I am inclined to merge this PR as it is and then fix the remaining places directly. I'll wait a few (10?) minutes before starting that process, in case @phil-blain or anyone else is working on this simultaneously.

Once that is done, we will need to bring the Icepack CONTRIBUTING.md and README.md files in line with these.

[eclare108213]

Since we seem to have reached consensus on what should be done, I will go ahead and merge this PR, and I will fix the remaining items directly. I'll post my progress and and resolve the conversations in this PR as I go. We can continue to improve all of these files and wiki pages, as needed.