Wikimedia Developer Summit/2018/Writing Tips/Examples

Here are three highly unofficial example position papers. This may or may not be what the program committee is looking for. Hopefully we'll collaboratively edit these to make them match the desired format.

Seeds should be planted point-up
I believe that tomato seeds should be planted point-side up. This may seem like a trivial change for our project, but it could have a real and lasting impact. Seeds grow better point side up, and most sowers coming from the community expect to sow them that way. But our existing fields contain a wide variety of seed orientations. In fact, when our field was originally sown we settled on a point-side-down convention for a number of years.

Switching to point-side up made a 5% improvement in germination rates in one small section of the field I tested. Other nearby fields have reported germination rate improvements of up to 25% by switching to point-side up.

If you are planting seeds by hand, switching to point-side up is straightforward. Simply put the seed in the ground point side up.

However, many developers on our projects use the Model X Seed Insertion Tool (MXSIT). When using MXSIT, you have to counter-intuitively insert the seeds in the linear hopper point-side DOWN in order to have them inserted in the soil point-side UP. This feels strange at first, but I can testify from personal experience you soon get used to it. Further, our sow review process can automatically detect the incorrect seed insertion and provide guidance about how to fix your tool.

The MXSIT also has a “bulk hopper”. Unlike with the linear hopper, there is no way to control the orientation of seed insertion using the bulk hopper. We would likely have to ban use of the bulk hopper. It is possible we could also design a machine to go through the sown rows and orient the seeds properly as a post-sowing step. I don’t know whether enough community members use the bulk hopper for this to be a practical concern.

I expect it would take three engineers a year to dig up all our already-sown fields and ensure the seeds are all point-side up. There are tools which could help, but no tool is perfect. It is possible that tooling could reduce the time to six months.

However, simply ensuring that all new fields are sown point-side-up could be done with very little effort. There are only two things that have been preventing us from making this change: This is a straight-forward matter; we should simply make the decision and commit to it.
 * 1) It turns out that point-side-down seeds adjacent to point-side-up seeds germinate worse than either by themselves.  So incremental conversion is problematic; in order to reap the benefits (as it were) we must really commit to converting all of our old point-side-down fields to point-side-up in a reasonable timeframe.
 * 2) Since the change is only beneficial if the whole project shifts, no one has yet felt they had to authority to dictate point-side across all our fields.


 * Notes
 * This is about 460 words.
 * This is intended to be a "low-level" position paper. Something like "we should eliminate the use of   in our codebase" (if that makes any sense to you).
 * I hope the program committee can give feedback here: "How low is too low-level?" This could provide guidance for folks thinking of writing a position like this one. Is this acceptable? Should you aim your sights higher?  Is there another more appropriate venue for low-level proposals which have failed to make it through existing processes for whatever reason?

Switch to Modern Latin
I believe the proper language for tomato-oriented tasks is Modern Latin.

It is true that most of our workers currently write in Old Latin, and the vast majority of our scrolls of tomato lore and working incantations are written in Old Latin. To be fair, this was a modern language at the time our project was started, and the Catholic Church maintains a large library in Old Latin. Furthermore, many Foundation tasks can be accomplished with monks and friars borrowed from the Church, since we share the same written language.

However, even the Catholic Church has slowly begun to shift to Modern Latin. (And of course, Protestant churches write in the vernacular.) Present-day residents of Italy find Modern Latin closer to Italian and thus easier to understand. By switching to Modern Latin we could continue to gain the benefits of alignment with the Catholic Church, while also picking up a greater number of community members from Italy and surrounding regions.

There have been suggestions that we switch to English or Greek. Large corporations speak English, and it is good for writing contracts and other enforceable documents. But we feel it would be too great a change for our existing community: we may lose all of our current workers and have to rebuild our engineering staff from scratch. There is presently good commonality of purpose with monks and friars who speak Old Latin and Modern Latin, but the English-speaking community tends not to prioritize the nonprofit cultivation of tomatoes. We feel the disruption to our community and mission would be too great.

Greek is a common trade language, and it has a large sea-faring community. Further, shipyard technology seems to be developing at a very great rate, and portions of our project already use Greek where interaction with the maritime community is required. Comparing Modern Latin to Greek may be an interesting discussion to be had at the summit. It is not as implausible as English, but it would still be a very large shock to our community. It is possible that we’d end up with a larger community after the shock had passed, however.

Regardless, we should move on from Old Latin, now that the Catholic Church itself has done so. Sticking with our original language from this point forward will only further isolate our community. I believe that the most practical solution is to move to Modern Latin, although I believe those who favor Greek are not entirely mistaken.
 * Notes
 * This is about 393 words.
 * This is intended to be a "medium-level" position paper. Something that has a large effect on our project, community, and/or codebase, but can be described and discussed (at least initially) without a lot of low-level project-specific technical detail.

Pizza is the future of tomatoes
I believe that pizza is the future of tomatoes.

Surveys of the consumption of tomato-containing foods have made this very clear. Pizzerias are growing year-by-year. Consumers of pizzas tend to be younger and more diverse than our existing tomato consumers. Traditional Italian cooking in homes has undergone a drastic decline, although Italian restaurants are likely to remain popular for some time. Although it is clear we can not completely ignore traditional Italian dishes, we should focus our efforts on ensuring that our tomatoes are best suited for pizzas, whether prepared in a pizzeria or at home.

There are a number of ways we could better focus on pizzas.

First, it is well known that red tomatoes are preferred for pizza. Our efforts to cultivate orange, yellow, and green tomatoes should be spun off for community maintenance. We expect that the fried green tomato community will be able to maintain a fork for their purposes.

We have also preserved a “whole tomato” recipe book for using the tomatoes we cultivate---but pizza doesn’t require whole tomatoes, it requires purées. In fact, even most Italian dishes use puréed tomatoes these days. The focus on “whole tomato” processes has made it difficult to modernize our operations. We should end-of-life “whole tomato” applications and focus on new users who will be consuming purée. Again, we expect that “whole tomato” users, like vendors of Caprese salad, will either fork the project (no pun intended) or take our tomatoes earlier in our process and maintain their own processes that ensure the skins of their tomatoes are preserved intact.

We should also write a new recipe book for pizza applications. It’s not worth trying to keep the 10 or so pages of our existing recipe book which deal with pizza-related topics; we should write a new book from scratch, putting pizza first.

Italian is the universal language of pizza. We should begin to translate more of our tomato lore into Italian, and ensure that any new projects are in Italian. We should invest in building better connections with the Italian community. Shockingly, most of our employees live in the San Francisco area and very few in Italy itself. Although San Francisco has very good pizza restaurants, they do not compare with local knowledge. We need to actively recruit new Italian employees, and possibly open a small branch office in Italy. We should ensure that company-wide meetings are compatible with Italian time zones. We may need to create a new Italian Department to coordinate projects which help change our focus.

I hope the summit will agree that pizza is the future of the tomato, and can further develop a plan of action to reorient the Foundation around this principle.
 * Notes
 * This is about 446 words.
 * This is intended to be a "high-level" position paper. A broad overarching idea, and then a few paragraphs diving into specific technical proposals which follow from the big idea.  A reader could agree with the big idea while disputing certain of the corollaries.  Or one could agree on the worth of a corollary while disagreeing that we should reorient entirely around the big idea!

Qualifications
There has also been some discussion on including more personal information about your qualifications for participation in the summit. I'm not certain how that is going to be collected. Is that part of the position paper? Or a separate form?

Regardless, it impacts the blind review process.

Keeping the tomato analogy here, here are three possible things you could say to establish your qualifications for one of the above position papers: I'm nervous about breaking blind review, but probably statements like #1 above would be acceptable and possibly useful. It would help alleviate the concern that reviewers might assume a submitter was simply unaware of the state of the art, rather than responding to deficiencies in the present state of the art.
 * 1) I am a tomato farmer.  I've grown over a thousand tomatoes.
 * 2) I am a CEO of a large tomato processing company.
 * 3) I am Howard Heinz.

Statement #2 seems to seek extra authority for their position by attributing it to a large company rather than an individual.

Statement #3 blatantly breaks blinding, and also seems to dangle a financial reward: if this position paper is accepted, funding may flow more freely.

More guidance on this matter would be helpful.