It's amusing how a seemingly innocent ad for a new tool can ignite a rather prickly thread.. I see two keys to this.
Firstly, for those who are not familiar with the issue the add could be better structured by providing a clearer statement of what the problem is or why it is important (with appropriate citations as examples) and then addressing how this is solved using the tool being advertised (ContaMiner). Second, I can't agree more with with Gerard: "a word of warning" (concerns about Staraniso use) is best to discuss with respective developers first before going public. (A nuance though is: not all developers are keen to open-access source code or even allow their software for benchmarking by others in some instances. So this may be tricky sometimes.) Radu's assessment is harsh to my taste.. I guess others commented on this enough to explain the validity of effort. Plus, I find wording "on the bizarre ContaMiner" isn't helpful. All in all, intentionally or not, this made enough of advertisement for ContaMiner and Staraniso! Win-win, I think! All the best, Pavel On Thu, Nov 23, 2017 at 10:33 PM, Graeme Winter <graeme.win...@diamond.ac.uk > wrote: > Dear All, > > As someone who is both a user of external software and supports internally > developed software to external users, I am quite familiar with both sides > of this argument. From time to time someone will notice a "weird feature" > in software - sometimes this is a bug, sometimes misuse (which is still by > and large a bug, but in documentation) and sometimes a change in > circumstances i.e. reasonable assumptions made in developing a package > (e.g. background always over 1 count / all data sets have some reflections > with I/sigI > 3 etc) become problematic. > > As an individual developing software, and a member of a team doing so, it > is always more comfortable if a user comes back with a collegiate "quiet > word" that the software did something odd. However, I suspect it would be > for the greater good that a more public approach was taken in general, > since the less attentive user may miss this odd feature and take the > results as gospel - if the knowledge of the bug / feature whatever was not > in the public domain. Despite appearances people do not like to contact > authors of software packages to complain. > > To make a note that "this version of package xyz has been found to be > sometimes unpredictable with version 123 of the pipeline" does not blame > the package, or the pipeline, but says that you should be warned with this > combination. Ideally the authors of package xyz and the pipeline would be > alerted, by the other developers or users, but it is better (IMHO) to be > open. Public bug trackers are a good example of this. > > I suspect this matter of anisotropy correction is a similar one. Here we > have a change in circumstances - the actual intensity measurements are > modified - and passed in as if they are the originals. It is reasonable > that this may affect the outcome of subsequent analysis and it is hoped > that this does change the outcome but in a positive manner. This does not > appear to be the case here. > > I have been asked on several occasions to incorporate the anisotropy > correction into xia2 as it 'always makes things better', and have resisted > on the grounds that the purpose of the package is to faithfully analyse the > data as provided and provide uncorrected intensities as output. The > corrections should ideally be performed within the downstream software, > since they then know exactly what has happened to the measurements and will > make fewer (ideally no) incorrect assumptions. > > It's already routine to write out multiple versions of e.g. phases, > weights, sigma values etc based on different assumptions and flag then > accordingly - perhaps we should be doing the same with modified > intensities, so that packages which require the unmodified values could > ignore the corrected ones. That would avoid the need for any health > warnings and ensure changes in the wider environment do not invalidate > assumptions... > > Obviously, all of the above is my humble opinion and other opinions are > equally valid. > > Best wishes Graeme > > > -- > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not > use, copy, retain, distribute or disclose the information in or attached to > the e-mail. > Any opinions expressed within this e-mail are those of the individual and > not necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any > attachments are free from viruses and we cannot accept liability for any > damage which you may sustain as a result of software viruses which may be > transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England > and Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom >
