Sharing methods without exposing people

A useful method and the material used to develop it are different things. A checklist for reviewing a proposal might be shareable; the proposals that taught its author what to check might have been entrusted to them in private. If you want others to benefit from your work, making that distinction is part of preparing something worth releasing.

Sharing gives other people a method they can inspect, adapt and improve. It also gives the author a chance to learn where the method fails. I value that exchange. The original wording, though, asks too much if “publish” is read as an unconditional instruction.

An illustrative release decision

Suppose a team develops a tool that checks whether a document package contains its required attachments. The checking logic could help other teams. Its examples, however, come from private submissions and include filenames, comments and fragments of the original documents.

A careless release changes the people’s names and leaves the rest. A reader familiar with the circumstances may still recognize a distinctive request or an unusual sequence of events. The examples can also contain information that should remain private even if nobody identifies its owner.

The responsible release starts by establishing that the team has authority to share the code and its dependencies. It creates fictional examples designed to exercise the same checking behavior, then verifies that those examples are sufficient to explain and test the tool. Someone reviews the proposed package, including documentation and any history that will be made public, for retained private material.

The test of that package is whether a stranger can understand what the tool does and try it without needing the original submissions. If they cannot, more explanatory work is needed. Publishing the source material to save that work would transfer the cost to people who never agreed to have their information used as an example.

The W3C’s guidance on publishing data considers privacy, commercial sensitivity and security, including the risk of identifying people by combining information. A release review should consider what the proposed material reveals alongside what is already public, even when each individual detail seems harmless.

Some mechanisms should stay private

The distinction between method and material does not settle every release decision. The method itself may disclose a business process that must remain private. Its author may lack the right to publish it. A security technique might be useful to defenders while also exposing an unresolved weakness that would put people at risk.

Those are genuine limits, not reasons to pretend a less informative release is equivalent. Sometimes a general description can be shared safely. Sometimes publication needs coordination with others. Sometimes the responsible choice is not to publish the mechanism at all. General usefulness does not create permission.

There is a practical burden after publication as well. A method released without its assumptions can invite uses it was never designed to support. State what it does, where it has been tried and what remains untested. An open license should make reuse terms clear; it does not demonstrate that the method is appropriate for every new use.

A suggested refinement

I would make the condition explicit:

Share reusable methods when you have the right to do so and can do so responsibly; protect personal and entrusted information.

This is a proposed refinement of principle 11, not a change to the words existing signatories signed. It preserves the preference for sharing while recognizing that privacy, rights and security can govern the method itself.

For the attachment checker, that means releasing an authorized tool with purpose-built examples and enough explanation to use it. If a private detail seems indispensable, examine what the reader needs to learn from it. Often the work is to express that lesson clearly without carrying the original person’s circumstances into public view.