最近有很多关于ImageJ开发的讨论。也许对话很棒，但在某些情况下，类似的观点散布在几个不同的线程中。我们过去筛选了最近感兴趣的话题（2-3个月内），并确定了一些关键主题。为了更好地组织讨论，我们正在创建新的线程，每个主题一个，把每个线程发送到适当的邮件列表：
- ImageJ 用于非程序员表达了浓厚兴趣的讨论
- ImageJX用于有关软件工程（技术、来源代码等）的高技术性讨论
我们发送到ImageJ users list的主题是：
- Backwards compatibility – “接近100%兼容”是什么意思？这是一个合理的、有保证的目标吗？
- ImageJ project structure – ImageJ、Fiji、ImageJX 和 ImageJDev 是什么，它们之间有什么关系？项目分叉怎么样？人们如何做出贡献？
- ImageJDev.org website – 网站的作用是什么？我们有什么改进呢？
- §§§5§§必要§ – ImageJ相关邮件列表的数量不断增加。它们有用吗？我们需要任何额外的清单吗？
- Scripting languages and API – 有些人希望 ImageJ 基于通用基础 API 支持多种不同的脚本语言，而另一些人则采用简单的、易于学习的宏语言。这么多方法的优点是什么？
§以及§§6§§§的线程：
- Image data types – 图像通常用“数据类型”表示，例如8位无符号整数、32位浮点等。我们如何让开发人员在编写图像处理实例时担心数据类型？一般支持新数据类型（例如复数）的最佳方式是什么？Scala @specialized 标签？
- Coordinate systems – 科学领域（例如天文学）中的数据图像可能具有比均匀间隔的某些图形网格更复杂的域集。我们应该努力支持这些数据吗？
- Separation of concerns (MVC, AWT/Swing/etc.) – 我们能否将ImageJ用户界面与数据结构完全解耦？我们为什么要这样做？
- Plugins infrastructure – 已经完全提出了多个增强插件模型的主题，例如，显式声明输入和输出类型，以更轻松的插入插件链接到工作流程中。有些人甚至建议消除“插件”的想法（而不是脚本/宏）。存在各种促进数据处理工作的框架（例如 KNIME 和 Cell Profiler）——我们可以学习什么，集成是否有意义？
- Performance – 我们如何提高ImageJ的算法性能？语言翻译？性能包？OpenCL？
请回复您感兴趣的任何主题。 Curtis Rueden将在今年余下的时间里休假，但会在1月7日之前回来，并会在允许的情况下尝试加入。传染病精彩的对话能够继续下去，我们将在接下来的几周和几个月内完善希望ImageJ的路线图！
