Problem Wiki

[stalepretzel]

When you answer a question, you are given the option of viewing the "forum" for the question. This "forum," however, usually consists of 100 solutions posted, with little explanation.

I propose that each answer also has a community-editable wiki that anyone who solves can answer. It would be like a dynamically-edited solution guide (the files that are attached to some of the earlier problems). Doing so would allow all the insight to surface, without the looming mountain of "here's my code" comments.

Yea? Nea? Comments?

[3n1gm4]

There is the pdf thing to show a valid method to solve the problem. Anyway there are very few pdfs, maybe because it may be tricky do make one and give it to moderators.

A wiki (not as substitute of the forum, still very useful to discuss about the problem, but as an addition to it) would be very cool :O It's easy to write/edit and could be more esplicative about different methods than actually browse trough all the forum.

[traxex]

I've been thinking about this idea a bit and searched the forum to see if it had been discussed before. I only found this short thread from 2008(!).

I know the PDF overviews are currently the official format for describing solutions, but very few problems have them. I think a wiki page that Eulerians can edit collectively might be much more successful.

A minimal implementation of this idea could be a special post on the forum that anybody can edit. It could be a "sticky" that appears before all others, or it could be behind a link next to the "PDF overview" and "Best posts" links. Eventually it would be nice to be able to view the edit history and perhaps even have a discussion page for the wiki page, so a simple wiki engine is maybe needed.

(As an aside, it took me a very long time to notice the star that links to "Best posts". If it was next to the page number links, perhaps to the left of "1", it would be easier to spot.)

Some advantages of a wiki:

- Many old posts are hard to read because their formatting is ruined. Usually they're using obsolete tags or have unescaped dollar signs that blow up. The wiki page could provide fixed versions of these and link to the originals posts to give credit.
- Sometimes the best posts are buried deep and most users will miss them. Problem 10 is a case in point, which also shows that a well made PDF can become partly obsolete since it can't be edited easily.
- Eulerians are already familiar with the formatting used in the forum. Creating an initial version of the wiki page for a problem would be as simple as copy-pasting from the most important forum posts.
- StackOverflow is similar in many ways and shows how well this format can work.

[euler]

It's certainly an interesting idea and I'm not dismissing it outright, but it is thwart with possible problems.

Although the Wiki modules have already been written and do everything we'd need, integrating Wiki with our own authentication procedures would probably require more work than I'd be willing to undertake. That is, access would be restricted to those who have solved that particular problem.

It should never become a code repository, giving people the opportunity to copy and paste their version of their solution using their preferred language. You could imagine if there were several different approaches to a problem and the page was filled with Python versions, C++ versions, APL versions, and so on, for every possible approach. Editors would have to use a generic pseudo-code. Who is going to monitor this? Then there's the problem of procedural/imperative languages versus functional and other non-imperative languages. Where would we draw that line?

Long term storage of previous iterations could become costly in terms of DB size. In which case, legitimate, multiple edits versus malicious, cyber-vandalism is always going to be an issue. That would require some significant working out.

Quality control! There is a very fine line between recognising personal stylistic preferences and poorly presented ideas, and it is often highly subjective. If someone is the first to write an explanation of one approach and a second person thinks that their way of expressing it is superior and of greater benefit to the community, then who is going to decide? Who is going to take responsibility for disputes over such matters? There are over 600 problems that would need to be monitored.

As I said, I am not against the idea in principle, but without proper thought and promises of reliable, long term support from members of the community, this could turn out to be far more trouble than it is worth. This is not something the problem development team or administrators should be expected to undertake, on top of how hard they already work to keep Project Euler running so well.

[traxex]

You raise good points and I agree with them.

I certainly wouldn't expect the problem development team to spend any time on this.

It would probably be best to limit editing rights to a team of editors. This would mean that there's no need to store edit history or worry about vandalism, and we could do without a wiki engine entirely, since the "sticky forum post" implementation would be completely fine.

Making it possible for the the top 1% of Eulerians (for example) to suggest edits would keep the traffic reasonably low while also having the collaborative wiki aspect and making it possible to gradually improve the content. This could be as simple as providing an email address that the editors will monitor. PMs on this forum could also be used if the usernames of the editors are known.

The question of which programming languages to use essentially already exists for the PDF overviews. I think pseudo-code and English descriptions would be sufficient since we can always refer to posts in the forum for concrete implementations. The choice could also be made on a case-by-case basis like it seems to be done for the PDFs, and common practices would be allowed to eventually form on their own.

I've thought about writing up PDFs for some problems a few times, but I would first need to learn more TeX, and without a sample template the effort it would take just to get started has discouraged me from trying. Also knowing that if the PDF gets rejected, anyone wanting to work on the same problem will probably have to start from scratch. But collecting the main ideas from the forum in a single post and presenting them in a consistent way is something I'd love to spend time on.

So in summary, I'm suggesting an alternative to the PDF overviews with just this difference: instead of downloading a file, clicking the link will display a page with a single forum post; and if the logged in user is one of the editors, he will be able to edit it. When the post is empty or doesn't exist, the link would only be visible to editors.

[euler]

Again, some good points, traxex. I must say that I am much preferring the idea of having "overviews" as a forum style post. Both the consistency of appearance and the ability for it to be easy to edit is a major plus.

The problem with limiting the size of the team of members with editing rights is that we lose one of the major benefits of allowing members to contribute to this in the first place. If we limited it to, say, the "top 1%", then it is unlikely that they would be highly motivated to go back and contribute to the earlier problems. That's not through laziness, but it would mean having to re-evaluate a problem completed many, many sleeps ago. The best people to contribute would be those who have just solved it, but then we face the dilemma of allowing the newest members to contribute would potentially allow an malicious individual to create new accounts just to ruin the content. Even if we set the threshold to, say, 25 problems (level 1), a determined, but nasty piece of work, would sadly take the time just to do that.

I suppose one solution would be to do something like limiting the number of edits per day a member is allowed to perform to his/her current level. But then the problem would be detecting a malicious change before he/she moved to the next problem. It could take days before someone notices that damage has been done. Having an email system, which notifies "team members" of any changes to content comes back to, "Who is going to take responsibility for that?" If the team is too large, then they may all assume that someone else will check it out. If it's too small, then it becomes a burden. It could have a flagging system, that would continue to notify them until someone approves it, but then it becomes increasingly complex to implement and getting constantly pestered with a "The overview for problem X has recently been changed, please check to approve the edit" email, because no one else can be bothered checking it, would be annoying.

In a perfect world, this idea would have emerged in the early days of Project Euler and we'd already have a vast array of such overviews. Over time they would have been edited close to perfection and everyone would have been benefiting from them. It is not a perfect world. There is a terrifyingly vast amount of work that would lie ahead to create initial content for all of the problems, and finding a reliable, efficient system of allowing edits still presents a challenge.

However, I am still very much liking the idea. So kudos to stalepretzel for the suggestion!

[traxex]

The problem with limiting the size of the team of members with editing rights is that we lose one of the major benefits of allowing members to contribute to this in the first place.

Perhaps a good middle ground would be to assign a state to each overview: Empty, Draft, or Finished, say. Initially all overviews are Empty and all users can edit them since there's nothing to vandalize. When an overview is in a reasonable state, it could be flagged for review by the user who created it, and then an editor could promote it to Draft. This would restrict editing rights to users at level X. If someone spends a significant amount of effort on the overview and it's on a comparable quality level to what's expected of the PDF overviews, it could be reviewed again, promoted to Finished, and the editing rights could be restricted further. For many problems there's not a whole lot to say and no need to keep editing forever.

Perhaps even two states would suffice, "Unlocked" and "Locked". But whether two or three, this way all users would be able to contribute, and the window for possible vandalism would be limited.

If we limited it to, say, the "top 1%", then it is unlikely that they would be highly motivated to go back and contribute to the earlier problems. That's not through laziness, but it would mean having to re-evaluate a problem completed many, many sleeps ago.

Speaking just for myself here, but I'd actually like to have an excuse to revisit many problems. There have been dozens of problems, even fairly easy ones, where I saw superior solutions discussed on the forum but instead of taking the time to really grok them I just said to myself "solved is solved" and went to a new problem.

I understand your concern about having enough volunteers to make this work. If something like this gets implemented, I'm willing to commit at least a few hours per week for the foreseeable future to create overviews and review edits. Naturally I can only touch the problems I've solved, but linear interpolation tells me I'll be at 100% in a few months.

[hk]

I've thought about writing up PDFs for some problems a few times, but I would first need to learn more TeX, and without a sample template the effort it would take just to get started has discouraged me from trying. Also knowing that if the PDF gets rejected, anyone wanting to work on the same problem will probably have to start from scratch. But collecting the main ideas from the forum in a single post and presenting them in a consistent way is something I'd love to spend time on.

Tex isn't necessary, probably even too cumbersome.
You can also use Word or Open Office to create a file and save it as PDF.

The concerns Euler had about the number of people working on the wiki-idea combined with the fact that they should be responsible for the thing for a long time makes me sceptical about the wiki-idea. We've the PDF thing and I would prefer it if that was ported further by the members. If they don't everything stops for me as I doubt that other ideas will be viable if the PDF thing isn't.

[traxex]

Well, I'm even less familiar with wysiwyg word processors than with TeX. I know they have some support for mathematics, but as an example, figuring out how to convert my post in the #612 forum into Open Office seems like a frustrating and pointless exercise. But I was happy to spend hours editing and gradually improving that post over a couple of days.

I doubt that other ideas will be viable if the PDF thing isn't.

Most problems have some very detailed posts written by members. Clearly members are (and always have been) willing to explain their solutions and educate others, but not so willing to create PDFs. I think you're underestimating how big a difference the format makes.

In any case, it's up to the team. I just wanted to add my Yea to this thread.

[drassont]

Excuse the bump but how exactly does one submit overviews? I'd guess there are plenty of Project Euler users who would enjoy writing overview PDFs for particularly elegant problems; I personally would very much welcome the opportunity to write about the problems I've solved in a way that explains their connections to deeper mathematical concepts, whether by a Problem Wiki as suggested here or by writing LaTeX overviews.