{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "chem-bla-ics",
  "description": "Chemblaics (pronounced chem-bla-ics) is the science that uses open science and computers to solve problems in chemistry, biochemistry and related fields.",
  "home_page_url": "https://chem-bla-ics.linkedchemistry.info/",
  "feed_url": "https://chem-bla-ics.linkedchemistry.info/2008/12/08/peer-reviewed-cheminformatics-2-code.json",
  "icon": "https://chem-bla-ics.linkedchemistry.info/assets/images/chem-bla-ics_logo.png",
  "language": "en",
  "authors": [
    {
      "name": "Egon Willighagen",
      "url": "https://orcid.org/0000-0001-7542-0286",
      "_orcid": "0000-0001-7542-0286"
    }
  ],
  "items": [

    {
      "id": "https://doi.org/10.59350/dm9c0-tzs46",
      "url": "https://chem-bla-ics.linkedchemistry.info/2008/12/08/peer-reviewed-cheminformatics-2-code.html",
      "title": "Peer reviewed Cheminformatics #2: Code review for the Chemistry Development Kit",
      "content_html": "<p>Peer review is an important component of open source development, and recently there was the discussion the other way around, if open source is\nrequired for peer review. Depends on your definition of peer review: No, if you restrict peer review to what it is in publishing (see\n<a href=\"https://chem-bla-ics.linkedchemistry.info/2008/11/12/re-open-source-peer-review.html\">Re: Open Source != peer review <i class=\"fa-solid fa-recycle fa-xs\"></i></a>); Yes, if we really want to speed up\ncheminformatics evolution and assume unrestricted, open peer review where reviewers can openly publish there review report with all the greasy\ndetails (see <a href=\"https://chem-bla-ics.linkedchemistry.info/2008/07/22/peer-reviewed-chemoinformatics-why.html\">Peer reviewed Chemoinformatics: Why OpenSource Chemoinformatics should be the default <i class=\"fa-solid fa-recycle fa-xs\"></i></a>).</p>\n\n<p>The <a href=\"http://www.chemistry-development-kit.org/\">CDK</a> has a strong history of peer review. Patches have been available from\n<a href=\"http://cdk.svn.sf.net/\">SVN</a> from the start, and later we instantiated a mailing list so that people could easily monitor code changes, and\nI have actually being doing this since the start, scanning the code patches, knowing that a lot of code is backed up by unit tests to detect\nregressions. Anyone can review CDK code in this manner, just by subscribing to the <a href=\"https://sourceforge.net/mailarchive/forum.php?forum_name=cdk-commits\">cdk-commits</a>\nmailing list. If one has questions or comments on a patch, a reply to <a href=\"https://sourceforge.net/mailarchive/forum.php?forum_name=cdk-devel\">cdk-devel</a>\nis all that is needed to get things going.</p>\n\n<p>About a year ago, CDK development had become so extensive that code review in this manner was no longer the way forward (though still possible,\nand still used). However, it turned out that it was all too easy to overlook a patch or just click it away in busy times. This was experienced\nby some developers who previously monitored the cdk-commit messages sketched above. So, we moved to a more formal patching system where any\nnon-trivial patching is done in a SVN branch. Once the primary developer is happy about the branch, (s)he requests a review by other developers.\nThese can leave comments in the source code, reply to the mailing list, or leave comments in the <a href=\"https://sourceforge.net/tracker2/?group_id=20024&amp;atid=320024\">CDK patch tracker</a>.\nThis more formal work habit got into action about half a year ago already.</p>\n\n<p>A <a href=\"https://sourceforge.net/mailarchive/forum.php?thread_name=200812041823.25546.stefan.kuhn%40ebi.ac.uk&amp;forum_name=cdk-devel\">recent message</a>\nfrom Stefan makes clear that this tracker has some room for improvements. For example, there is no automatic email to cdk-devel when a patch\nhas not been tended to for a longer period of time. And, I do not see a simple way of doing this with the SourceForge bug track system.</p>\n\n<p>But, what I can do, is define a number of groups to represent the state of the patch. So, I defined:</p>\n\n<ul>\n  <li><a href=\"https://sourceforge.net/tracker2/?func=browse&amp;group_id=20024&amp;atid=320024&amp;status=1&amp;artgroup=896890\">Needs Review</a>: this patch has not been reviewed (sufficiently) yet</li>\n  <li><a href=\"https://sourceforge.net/tracker2/?func=browse&amp;group_id=20024&amp;atid=320024&amp;status=1&amp;artgroup=896891\">Accepted</a>: but not yet applied to SVN yet. When applied, the patch report is simply closed</li>\n  <li><a href=\"https://sourceforge.net/tracker2/?func=browse&amp;group_id=20024&amp;atid=320024&amp;status=1&amp;artgroup=896892\">Needs Revision</a>: the reviewers like to see changes made to the patch</li>\n</ul>\n\n<p><img src=\"/assets/images/cdkPatching.png\" alt=\"\" /></p>\n\n<p>Not perfect, but a step forward in tracking the state of patches.</p>",
      "summary": "Peer review is an important component of open source development, and recently there was the discussion the other way around, if open source is required for peer review. Depends on your definition of peer review: No, if you restrict peer review to what it is in publishing (see Re: Open Source != peer review ); Yes, if we really want to speed up cheminformatics evolution and assume unrestricted, open peer review where reviewers can openly publish there review report with all the greasy details (see Peer reviewed Chemoinformatics: Why OpenSource Chemoinformatics should be the default ).",
      "image": "https://chem-bla-ics.linkedchemistry.info/assets/images/cdkPatching.png",
      "date_published": "2008-12-08T00:00:00+00:00",
      "date_modified": "2025-10-11T00:00:00+00:00",
      "tags": ["cdk","openscience"],
      
      
      
      
      
      
        "authors": [ { "name": "Egon Willighagen", "url": "https://orcid.org/0000-0001-7542-0286" } ]
      
    }

  ]
}