Launchpad projects need wikis

I would like to add my voice here to hopefully add more attention to this issue.

Lauchpad is an almost complete (and most awesome) project hosting site, and when I searched for a code hosting for my project (released a year ago), I looked no further as the set of features seemed complete.

However, as others started joining in, it became necessary to start a mailing list, and launchpad did not offer them. So, I had to look elsewhere. So, now I have most of the project data in one place (launchpad) and the mailing list elsewhere (google groups). While both services are free, there is a barrier to contribution since people have to register for two different sites: one to report bugs and one to chat.

Now many people are asking for a Wiki. Again, I can probably find a free wiki hosting service, but I'll run into the same problem again. Now people have to know about three sites (actually four, since the project's main web site is also somewhere else). This is not optimal.

Integration is key here. Launchpad/bzr integration is great (you can link bugs to fixes). Questions and answers, bug reports, fixes, blueprints, etc., are all nicely integrated. As Wikis are ubiquitous nowadays for soliciting user-contributed documentation, tips, and ideas, I think that adding a wiki under the same framework would be even better.

So, I have to say "me too", and thanks for all the great work.

Aziz,,,

> However, as others started joining in, it became necessary to start a
> mailing list, and launchpad did not offer them.

Well, actually Launchpad does offer mailing lists :)

*sigh* "Did" is past tense. It's obvious from the comment that they do now.

Has there been any headway on this? Launchpad guys? :)

I'd like to add my voice to this. Blueprints seem to be quite limited without the ability to collaborate around it. Having to link to an external wiki just seems strange...

launchpad-foundations regards all the Launchpad project base. Creating a wiki will effect the base, so it's more appropriate to set the bug valid to launchpad-foundations only.

Just thought I should add that Google Code has had wiki's for a long long time, and SourceForge has just launched MediaWiki hosting: http://www.readwriteweb.com/archives/sourceforge_announces_hosted_apps.php

One possible solution that would allow launchpad to add a wiki is adding a wiki folder inside of your repository and let the bzr repository manage the sourcecode of that wiki. This would look like this:

1. wiki folder gets created right next to trunk
2. launchpad provides a simple interface, edit, preview, save where permissions will be judged based on your membership/access to repository.
3. Would be great if wiki in itself be a moinmoin then parsing would be done by a moinmoin engine no work on launchpad other then setting it up.
4. I would be able to either edit the wiki via a web or just edit the wiki files using moinmoin syntax from within the repository.

This allows for easy syntax (moinmoin), allows for sourcecode edits/access, controls the permissions via repository. The only thing that needs to be done is for launchpad to list the files in wiki folder, render them using moinmoin engine, and provide edit,preview,save options. All history/reverts will be done by a user from within his bzr repository.

Hope this helps.
Thanks,
Lucas

I'll add that Google Code also uses a version-controlled wiki. That is, the wiki data is placed inside the project's svn repository, and the actual rendered wiki always represents the latest version. Similar to what Lucas suggested, edits can be done via the web interface (which generates an automatic commit), or via version control checkout-edit-commit.

It would be very nice to see something similar in Launchpad.

Yes, it needs one!

version-controlled wiki (bazaar, anyone?) would be too perfect :)

On Wed, Oct 15, 2008 at 9:07 PM, Martin Albisetti <email address hidden> wrote:
> version-controlled wiki (bazaar, anyone?) would be too perfect :)

Agreed. But the most important thing is just to have a wiki, any kind.
If it's VC, even better.

A 'moinmoin' type of wiki with VC would totally rock!

During last summer google of code there was some work done on moinmoin to allow for hg backend. http://hg.moinmo.in/moin/1.8-storage/ but I'm not sure how far they've gone. If it works then it could probably be easy to port the python code to use bzr.

Here is a link that describes the moin storage engine situation.
http://the-space-station.com/2008/09/07/my-work-on-moinmoins-new-storage-engine-gsoc-2008

I would like to second this request for a wiki. Bonuspoints for using version control for the wiki :)

I third the request. :)
 It's been something I've found missing for a long time and it's the only reason why I also have my project registered under a wiki hosting site as well. I even want this more because then specs can be stored at my internal launchpad wiki instead of at an external wiki site. (In the blueprints edit page, there should also be a "link to wiki page" option for the spec url then.)

Really, I'd just like a simple MoinMoin setup like the Ubuntu wiki. https://wiki.launchpad.net maybe?

+1 for Wiki integration with LP
It /could/ be done as a plugin to a separate Wiki to provide the integration, this is the key part.
However I too am looking around for separate hosting just for the Wiki component of my project...LP seems to be able to handle all the rest :)

The only thing that bothers me about a wiki version-controlled in bazaar is the large amount of commits it would cause. (Though, off course, this could be remedied by placing the wiki in a different branch.)

Google Code seems to get away with placing wiki entries in svn.

Even something as simple as a bzr-backed wiki branch that displays files as Markdown/Textile/whatever would be immensely useful.

On Sun, Jan 25, 2009 at 4:18 AM, Jacob Peddicord <email address hidden> wrote:
> Google Code seems to get away with placing wiki entries in svn.
>
> Even something as simple as a bzr-backed wiki branch that displays files
> as Markdown/Textile/whatever would be immensely useful.

Just a normal wiki would be nice. no need of bzr hacks

Having blueprints as wiki pages, and whenever they are accepted/validated having them 'locked' would be more than enough :)

No it wouldn't.

Where would you keep documentation, FAQ's and installation instructions?

On Tue, Jan 27, 2009 at 1:32 AM, Jorge (kad) Gallegos
<email address hidden> wrote:
> Having blueprints as wiki pages, and whenever they are
> accepted/validated having them 'locked' would be more than enough :)
>
> --
> Launchpad needs a wiki
> https://bugs.launchpad.net/bugs/240067
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Alwin Garside
Email: <email address hidden>
Blog: http://www.yogarine.net
Twitter: http://twitter.com/yogarine
MSN: <email address hidden>
Phone: +55 83 9127 5361

@Jorge
Perhaps for you, but not for me.

Where would you keep documentation, FAQ's and installation instructions?

As a workaround for the lack of a wiki, couldn't Launchpad give the
option to make a Bzr branch for every project accessible from the web?
That way one could upload htmls and images and link them from the main
project page ?
That would be very easy to do.

Actually, bzr branches are already available from the web, in some form. The problem is the files can't be edited from a browser, nor does it feature any kind of formatting.

> Actually, bzr branches are already available from the web, in some form.
> The problem is the files can't be edited from a browser, nor does it
> feature any kind of formatting.

Sample url ?

@TAC one
http://bazaar.launchpad.net/~vulpes-dev/vulpes/main/files

> @TAC one
> http://bazaar.launchpad.net/~vulpes-dev/vulpes/main/files

That's not what i meant.
I meant to have one of the branches of the project as checkout
accessible from apache.

Can you guys move this conversation into a mailing list, and not this bug.

Does launchpad have some financing available. Last google summer of code there was an implementation done to store moinmoin wiki on a different backend. I'm not sure but if there were money involved then maybe it could be used to pay for writing the bzr backend. If not any volunteers to talk to moinmoin developers on speeding up the process of "moinmoin on different backend"?

Thanks,
Lucas

Ha, so what you basically mean is hosting an automatically updated working tree of a branch through a http server? ;-) Well... That could be useful for developer documentation, but I prefer a wiki that integrates nicely into Launchpad and can be edited by users.

On Tue, Jan 27, 2009 at 5:01 PM, Alwin Garside <email address hidden> wrote:
> Ha, so what you basically mean is hosting an automatically updated
> working tree of a branch through a http server? ;-) Well... That could
> be useful for developer documentation, but I prefer a wiki that
> integrates nicely into Launchpad and can be edited by users.

Would be just a quick workaround - i.e. better than nothing.
In such case, the branch could be edited from the owners of the branch
(just create a doc-team for your project and, if you wanna make it
accessible to anyone, let it be a free group)

I agree with the utility of the "doc-team" use case that TAC notes. If there was a relatively clean url for the contents of the latest version of a given file, that would be most of what we'd need.

E.g. http://bazaar.launchpad.net/~vulpes-dev/vulpes/main/annotate/head%3A/src/README

but without all the surrounding chrome that would confuse an end-user. And of course I'd want it to be presented with an html mime type if it was an html file.

Sure, it'd have it's use, but it wouldn't be a wiki. End-users wouldn't know how to edit it, unless they learn how to use Bazaar. And it doesn't integrate nicely into Launchpad.

So, even if it would be useful, it's not relevant to this bug.

In my opinion, this should be implemented properly right away, so we don't end up migrating our docs from HTML to Wiki markup later.

Really, this has all got a bit out of hand. A simple MoinMoin wiki like the Ubuntu wiki would solve this bug.

> Really, this has all got a bit out of hand. A simple MoinMoin wiki like
> the Ubuntu wiki would solve this bug.

Yes, I completely agree.

Hi everybody,

Were there any updates on VC-controlled Wiki hosting ?
Thank you!

No, we are still committed to finishing our 3.0 cycle, where we update all the UI.
After September, we will plan the next year's worth of features, and the wiki is the #1 thing on our list ;)

Thank you, Martin ! Looking forward to see new UI

Very good news that wiki functionality is on the horizon after 3.0 release. I must say, both the UI stuff and strange requirements like linking to external wikis seriously diminish launchpad's attractiveness for small and simple projects (esp. compared to the very clean and simple Google Code). If simplicity could be coupled with the extremely strong collaboration features at would really serve all needs.

> We should however find what this need is.

I believe there is no need to reinvent the wheel...assuming that Github, Bitbucket, Google & SF did some research and decided why they offer wiki and visiting some of the project on those 4 hosting sites would, I assume, quickly yield the correct conclusion. :-)

Just spent 45 minutes updating the LEP. @lifeless Please comment.

Very excited to see activity on this bug. I'll be looking at the LEP as soon as I can. Am keen to avoid something that's a "bolt on" like our code browsing, and would also like something that's much, much snappier than that too.

Also, I don't know of any case where an open source web service has had a major new feature developed by new contributors. It's definitely the kind of thing I'd very much like to see happen on Launchpad.

I've done a pass over the LEP. Still very much in discussion phase right now. Keen to hear thoughts and to keep revising.

Are we integrating Ubuntu Wiki with Launchpad? I think that would be the best and easiest course of action.

No. That would actually be really difficult and wouldn't help much for projects.

@Robert Collins Can you please make another pass over the LEP? Thanks.

+1 Launchpad really must have a wiki. I would propose moinmoin. It has worked well for me in the past.

I am in the process of trying to find a new host for my company and bazaar would be preferable (although we might have to go with mercurial because of the lack of full featured hosts supporting bazaar.

One of the important aspects for us is that we can use one wiki for all our projects. We also need a bug tracking solution that lets us related bugs from multiple projects.

@Geoff - I will on the technical aspects of it ( I'm subscribed to the wiki anyhow). jml is going to be unavailable this week so it will need to wait for him to return.

@Julie hi. moinmoin isn't designed for mass hosting - and we're looking at tens of thousands of wikis. It is a possibility but there would be a chunk of work needed to go that route. We don't have a single-wiki-many-projects use case in https://dev.launchpad.net/LEP/Wiki at the moment. Would you like to add one?

Hi,

I opened a bug a while ago to be able to push HTML files via bzr to a
conventional branch name and be able to see these files served
statically by launchpad on a conventional URL on my launchpad project.

My bug was marked as a duplicate of this wiki bug, even though the
under-the-hood, the edition workflow, ressource usage and audience for
such a feature is very different than a Wiki application. One of the
main difference of my feature request is that I do not really want or
need to edit files via the browser, I am fine with my local text
editor.

The feature I describe is closely inspired from the <login>.github.com branch.

Now Github has came up with a feature which makes it super easy for
people to edit a file via the browser, github takes care of creating a
fork of the project and sends a pull request of your changes to the
owner of the file you edited.

https://github.com/blog/844-forking-with-the-edit-button

With Github, you can do both:
1. powerful local edit with vi/emacs,
2. simple through the browser edit

Keep up the good work on Launchpad,

Cheers

On Mon, May 30, 2011 at 7:59 AM, Robert Collins
<email address hidden> wrote:
> @Geoff - I will on the technical aspects of it ( I'm subscribed to the
> wiki anyhow). jml is going to be unavailable this week so it will need
> to wait for him to return.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (476472).
> https://bugs.launchpad.net/bugs/240067
>
> Title:
>  Launchpad projects need wikis
>
> Status in Launchpad itself:
>  In Progress
>
> Bug description:
>  Launchpad needs a Wiki unrelated to Ubuntu. When we opened our open
>  source project (ubuntu related, in a way) i was uncertain about being
>  allowed to use Ubuntu wiki to fill one (1) page about the project.
>
>  I really think you should provide a wiki to every project in launchpad
>  (maybe with the chance to choose to have an external one).
>
>  The rationale is:
>   - having an own wiki requires hosting. Why use launchpad for bugtracking and buying hosting space just for the wiki ?
>   - Ubuntu wiki is inherently unrelated for many of the projects.
>   - Launchpad's blueprints require an external site. This shouldn't be necessary
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/launchpad/+bug/240067/+subscribe
>

I've updated the LEP. Please someone review it and either move it back to 'drafting' or 'approved'.

Thanks.

Hi Geoff,

I read the LEP. It's good.

> As a developer of an open source software project I want a wiki so that I can provide documentation to my users and plan my features more easily.

This is true, but perhaps the LEP will be easier to reason about if
rather than just "I want a wiki" we talk about what they want to do,
not how, in the As-A section. The word "wiki" has many associations
such as being publicly writable, and we should be clear about whether
we mean that or not, or this just gets circular, and jumps to
implementation. Wikis are _not_ an ideal answer for all jobs for all
projects; we can possibly do better.

It does get into that a bit, further down: a homepage, documentation,
feature planning, announcements, etc.

I can definitely see how people would want richer formatting in
announcements. It's not obvious to me that people want to put their
announcements into Bazaar branches just to get wiki formatting in
them.

I wonder about splitting this into several parts, probably done in this order:

 * rich formatting of user text into html, probably coming from
Markdown (or maybe ReST): this would allow announcements, bugs,
project descriptions, etc to look a bit better
 * do this also for the contents of branches, especially for their
README and similar files
   - tangentially, show those files within the main lp ui
 * through-the-web-ui editing of branch files
 * wiki-type navigation within files in a branch

hth,
Martin

> I can definitely see how people would want richer formatting in
> announcements.

The way announcements are currently set up is so that you may link to an external website. The way it is done now in some projects is that they will put a "teaser" in the announcement, and then link to and external blog/website/etc. If we were to provide a wiki, they could simply link to a wiki page.

> It's not obvious to me that people want to put their
> announcements into Bazaar branches just to get wiki formatting in
> them.

Well, you wouldn't necessarily upload via bazaar, since in the "must have" section it mentions editing via web UI.

Actually, I was just planning on designating one of the project's code branches as the wiki branch, and then displaying the contents on http://wiki.launchpad.net/project-name. Of course, this would only display pages ending in .md, .txt, etc, and it wouldn't show a directory listing...

Really all I am waiting on is for someone to approve the LEP. (It's currently in the "Ready for review" section)

On 4 June 2011 01:35, Geoff <email address hidden> wrote:
>> I can definitely see how people would want richer formatting in
>> announcements.
>
> The way announcements are currently set up is so that you may link to an
> external website. The way it is done now in some projects is that they
> will put a "teaser" in the announcement, and then link to and external
> blog/website/etc. If we were to provide a wiki, they could simply link
> to a wiki page.

That's true, but I think ideally you would be able to have rich
formatting within the announcement itself, rather than just a link. I
think the key thing here is that the concept of rich formatting
shouldn't be limited just to the wiki area. It doesn't matter so much
which one is done first.

>> It's not obvious to me that people want to put their
>> announcements into Bazaar branches just to get wiki formatting in
>> them.
>
> Well, you wouldn't necessarily upload via bazaar, since in the "must
> have" section it mentions editing via web UI.
>
> Actually, I was just planning on designating one of the project's code
> branches as the wiki branch, and then displaying the contents on
> http://wiki.launchpad.net/project-name. Of course, this would only
> display pages ending in .md, .txt, etc, and it wouldn't show a directory
> listing...

Launchpad wants to get away from using different subdomains for
different functional areas, so it should probably instead be
launchpad.net/project-name/+wiki/... or something. This would be a
good place to start. I think the LEP would benefit from describing
what is going to be done in the first phase.

On 4 June 2011 05:17, Geoff <email address hidden> wrote:
> Really all I am waiting on is for someone to approve the LEP. (It's
> currently in the "Ready for review" section)

If you're planning to work on this yourself you don't strictly need to
block on LEP approval to start discussing the implementation, or even
working on the code.

At the moment there is nothing in LP that directly shows branch
content within the main web app; it only comes out through Loggerhead,
and through the code review stuff which is done in the background.
This is something we'd very much like to change, but it will need some
careful thought and discussion about how to do it in a safely fast
way.

We also need to decide whether to do this from the main webapp or a
separate process.

I would suggest starting a list thread about the implementation, as
distinct from the LEP which gives the requirements.

On Sat, Jun 4, 2011 at 12:08 PM, Martin Pool <email address hidden> wrote:
> On 4 June 2011 05:17, Geoff <email address hidden> wrote:
>> Really all I am waiting on is for someone to approve the LEP. (It's
>> currently in the "Ready for review" section)
>
> If you're planning to work on this yourself you don't strictly need to
> block on LEP approval to start discussing the implementation, or even
> working on the code.

In this particular case I have suggested we get consensus around what
we want to do: a poor (UI/concept/implementation) of a wiki in
Launchpad is something that wouldn't be accepted; I'd hate for Geoff
or anyone to put significant effort in and have it rejected.

-Rob

On 4 June 2011 11:52, Robert Collins <email address hidden> wrote:
> On Sat, Jun 4, 2011 at 12:08 PM, Martin Pool <email address hidden> wrote:
>> On 4 June 2011 05:17, Geoff <email address hidden> wrote:
>>> Really all I am waiting on is for someone to approve the LEP. (It's
>>> currently in the "Ready for review" section)
>>
>> If you're planning to work on this yourself you don't strictly need to
>> block on LEP approval to start discussing the implementation, or even
>> working on the code.
>
> In this particular case I have suggested we get consensus around what
> we want to do: a poor (UI/concept/implementation) of a wiki in
> Launchpad is something that wouldn't be accepted; I'd hate for Geoff
> or anyone to put significant effort in and have it rejected.

Same here. My point (maybe poorly expressed) is that what he needs is
a good clear plan, not for someone to rubber stamp it.

Right now I've proposed some changes to wikkid and I'm waiting on the driver to comment on those changes.

Hello everyone,

I've just done a big round of updating the LEP. Here's a summary of the changes:
 * Rewrote the "Rationale" to be a bit less strident and a bit more likely to convince folk around here to sponsor developmen
 * Updated to have a "User stories" section, which is something we're doing for all new LEPs
 * Pushed the markup requirements into "Must have"
 * Added a bunch of requirements that practically any off-the-shelf wiki would meet (page management, subscription management, printable pages)
 * Added a bunch of translation stuff to "nice-to-have"
 * Filled in the success metrics section
 * Moved implementation stuff into a separate section. Bazaar branches, wikkid, URLs.
 * Added lots of explicit must-have requirements for search

There were some debated points that I have made a decision about:
 * Attachments
   * These are essential, at least for images. https://wiki.ubuntu.com uses them, https://dev.launchpad.net/ uses them, wikipedia uses them.
 * Migration
   * Dropped this, but made "mass import" a nice-to-have
 * Bumped "privacy for wikis of private projects" to be a must-have

There are some requirements that I am unsure about, they are in the "Unsure" section. I have deleted some of the "discussion" there, because a lot of it boiled down to "I don't think so" and the document is getting pretty long.

OK, that's the summary done. Phew. Some more thoughts follow.

First up, I think we're making really good progress here in understanding what we want for our end users. The remaining points are things that, quite rightly, deserve some thought and conversation.

Second, the requirements we are gathering here are deliberately inclusive. We want to understand what it means to be finished, to have done this well. When someone proceeds with actually doing this, they will probably want to group the requirements together and deliver them incrementally, some one day, some another day. We

Third, it is genuinely important to set aside thinking about _how_ we'll do this in order to focus on _what_ we actually want to do. If anyone would like to think or wax eloquent about implementation approaches, they should please keep it out of the main section of the LEP. The ideal is that a LEP should be written in such a way that you could imagine three or four different implementation approaches.

Also, as a point of order, if you are making a comment on any wiki page, please say who you are and when you are making the comment, especially if "I think" forms any part of the comment.

Where do we go from here?

In no particular order, we need to:
 * Resolve the "unsure" requirements
 * Evaluate some choices of wiki technology (wikkid, mediawiki, moin, rolling our own, ...)
 * Break the LEP into sub-features / milestones / whatever. I'd suggest universal wiki markup as the first.

I really do hope this helps. Good luck.

jml

> mediawiki

I don't see how this has anything to do with launchpad:

1. It's written in PHP. I know PHP pretty well, and I'm sure I could adapt this to launchpad's needs, but adding mediawiki here will only make it harder to develop launchpad; you'll need to know two programming languages.
2. It doesn't use bzr branches.
3. It's poorly written. I'm sure this is debatable, but in my opinion, it's poorly written. This is a side effect of PHP applications: everyone knows PHP, so sometimes devs aren't that bright.
4. Nightmare integration. Good luck making mediawiki look like it's part of launchpad. I won't be the one doing it.

Now, I'm sure it would be fairly easy to destroy my #2 and #3 arguments. However, #1 and #4 are real problems; I don't see the point of putting in extra work here.

> moin

In order to be as unbiased as possible, I think this could work. However, it doesn't meet this requirement:

Use a standard, existing markup language so that new users have less of a hurdle to learn Launchpad

It also doesn't use bzr to store pages, which is kind of a downside.
> wikkid

Developed by a canonical employee, uses bzr, meets the most requirements out of any of the three wikis.

> rolling our own

Instead of using existing work with wikkid or moin, let's just waste extra time by re-inventing the wheel. If there is any logic in doing this, I fail to see it.

@xaav
the point of needing to do an evaluation is because its *not* trivially obvious hat implementation of 'wiki' we need. I'm not going to try and do that right now, but I will try and provide a framework for doing such an evaluation:
 - cost of maintenance - code we run needs to either be solidly maintained upstream, or we need to maintain it in the LP team
 - ease of achieving our integration goals
 - performance
 - expected quality of result

> If this isn't done in 3-4 months, I won't be fixing it. However, I will try my best to get something started on this.

At this point, it has been a few months, and as promised, I have put too much time pouring over the launchpad code and getting this plan pushed through, I'm busy with other things by now. The biggest problem here is it takes too long to change something in launchpad. If I was writing my own application, I could have something basic out in less than 5 days!

I really am sad to do this, and I really hope this bug gets fixed. It just seems there are too many bugs to fix and not enough people to fix them. Hopefully I have encouraged someone else to fix this bug by now, but if not it will get shoved down to the bottom of the list due to all the other problems has (about 5000 of them).

Sorry it turned out this way.

> At this point, it has been a few months, and as promised, I have put too much time pouring over the launchpad code and getting this plan pushed through, I'm busy with other things by now. The biggest problem here is it takes too long to change something in launchpad. If I was writing my own application, I could have something basic out in less than 5 days!

Thank you for taking time and initiative to bring wiki to the LP.

Unfortunately, this is/was one of the important features in our evaluating bzr/LP vs. hg/bitbucket and now seeing that in the foreseeable future we cannot expect any progress here , it's easier to decide for us to go via hg/bitbucket route.

> I really am sad to do this, and I really hope this bug gets fixed. It just seems there are too many bugs to fix and not enough people to fix them. Hopefully I have encouraged someone else to fix this bug by now, but if not it will get shoved down to the bottom of the list due to all the other problems has (about 5000 of them).

It's really too bad that LP devs do not see importance of this feature, especially considering that main competitors (github, bitbucket, google, SF) all have it. :-/

Sincerely,
Gour

I'd up-vote this proposal if Launchpad Bugs had a feature for voting on issues. ;-)

I'd vote up this issue, but I've pretty much migrated to Google Code and Github, so perhaps I should just unsubscribe from the bug. I'm surprised it wasn't more of a priority. It's been what, almost 3.5 years now?

You can essentially 'vote' on the issue by clicking "this bug affects me."

I had an interesting talk with MoinMoin's main developer Thomas Waldmann. In sum, I just think Moin 2 is worth a look, it's a big improvement compared to the 1.x series. But note that it's alpha and it *needs contributors*. As for scaling, it seems it does the trick. Please take a look:

* ThomasWaldmann: btw, storage got the final rewrite a few months ago, now much simpler, very flexible

* RenatoSilva: cool, do you think the code is cleaner and smaller?
* ThomasWaldmann: yes, a lot, old backend storage implementations were about 10x bigger

* RenatoSilva: I've heard some dudes from LP pondering about putting wikis available for projects, they were wondering what wiki engine to use, maybe moin2 if available can make them reconsider this...
* ThomasWaldmann: well, it is not ready yet for production

* RenatoSilva: just found a bazaar-based engine, maybe this one is what they're planning to use: https://launchpad.net/wikkid
* ThomasWaldmann: omg bzr, btw we killed the hg backend we had. we found it is just the wrong approach. But with the stuff we have now, we can sync on top of all those storage layers. this is more generic than doing it in the backend (we don't have the sync code yet, but we have revision ids, parent id, etc.)

* RenatoSilva: some people are suggesting moin, as well as wikkid, but the staff needs to test what wiki they need, iirc someone said moin would not scale well for the thousands of projects hosted there. Do you think moin could scale for thousands of wiki instances?
* ThomasWaldmann: it scales as well as anything else, how much ressources a wiki eats always depends on what you do with it and how. If you do stupid stuff, it will be slow. If you do a lot of expensive stuff, it will be slow also. Dvcs is wrong way to go. we also had that idea, but it just solves a different problem, not the problem a wiki has.

* RenatoSilva: I think the issue here is just a basic wiki instance for each project, the problem is that there would be thousands of wiki instances, so I imagine they wonder if moin server would handle them all well
* ThomasWaldmann: dvcs is great for managing a bunch of project (text) files in the filesystem. Few metadata (file name, mtime), data in file. And all files together define some state of your project. A wiki rather needs revision control for single items. But items do not necessarily need to be stored on the filesystem. Also, you do not just have data, but also lots of metadata (and that idea is no way new, hatta has done that also with hg). But you just can't sanely store wiki revision data into a file.

* RenatoSilva: but what solution do you think for "distributed wiki editing" (basically offline edits and their merges)
* ThomasWaldmann: it would need a enhanced filesystem, with unicode filenames of arbitrary length, with related metadata stored together with the file. Such stuff does not exist (sadly) and even if it would, it would be no way cross-platform. Distributed editing just requires to solve 2 problems: transferring the changes (this is rather easy) and merging (this can be hard and can not be automated for any case), and to know what one needs to do, one simply needs revids and parents

*...

We need a wiki for the Ubuntu Geek Squad. I think flexibility is essential. Mediawiki is definitely a no go!!!

The wikkid idea is great. You could mod_proxy the python server on ports to PROJECT.wiki.launchpad.net. Has anybody ever thought of this?

Please raise the importance flag. Having a reasonable documentation facility IMO is of high importance of such a environment.

thanks,

Andreas

This is probably mutually exclusive with bug 306378, "Knowledge Base feature". A wiki and a knowledge base aren't the same thing, but it would be overkill to have both.

Am 16.05.2013 18:49, schrieb Matthew Paul Thomas:
> This is probably mutually exclusive with bug 306378, "Knowledge Base
> feature". A wiki and a knowledge base aren't the same thing, but it
> would be overkill to have both.
>

suggest to mark 306378 as duplicate of 240067

Also a Wiki is more common nowadays.

> suggest to mark 306378 as duplicate of 240067
-1

knowledge base is different from a wiki, and a wiki is indeed a knowledge
base.

There is many ways to do a knowledge base, wiki is one option suitable for
many people and use case, and RST/markown based static html stored in a
VCS, like github's jekyll or readthedocs is better suited for other people
and use cases.

Cheers,

On Thu, May 16, 2013 at 7:51 PM, Andreas Roehler
<email address hidden>wrote:

> Am 16.05.2013 18:49, schrieb Matthew Paul Thomas:
> > This is probably mutually exclusive with bug 306378, "Knowledge Base
> > feature". A wiki and a knowledge base aren't the same thing, but it
> > would be overkill to have both.
> >
>
> suggest to mark 306378 as duplicate of 240067
>
> Also a Wiki is more common nowadays.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (476472).
> https://bugs.launchpad.net/bugs/240067
>
> Title:
> Launchpad projects need wikis
>
> Status in Launchpad itself:
> Triaged
>
> Bug description:
> Launchpad needs a Wiki unrelated to Ubuntu. When we opened our open
> source project (ubuntu related, in a way) i was uncertain about being
> allowed to use Ubuntu wiki to fill one (1) page about the project.
>
> I really think you should provide a wiki to every project in launchpad
> (maybe with the chance to choose to have an external one).
>
> The rationale is:
> - having an own wiki requires hosting. Why use launchpad for
> bugtracking and buying hosting space just for the wiki ?
> - Ubuntu wiki is inherently unrelated for many of the projects.
> - Launchpad's blueprints require an external site. This shouldn't be
> necessary
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/launchpad/+bug/240067/+subscriptions
>

--
جان دانيال براون

Just wanted to let subscribers know that I filed bug #1376166 as a (better?) related feature request.

Hi all :) As you know Launchpad haven't yet implemented markup support for tickets or wikis. Any additional volunteers for a patch. The team at Ubertus.org would be happy to contribute testing and documentation.

Meanwhile here is are a few free tools to do some basic text formatting with Launchpad. It works but it is not easy-breezy.

Convert plain text characters to obscure characters from Unicode, then the output is fully cut-n-pastable text to Launchpad at http://www.panix.com/~eli/unicode/convert.cgi?text=Is+Jorge+Castro+a+Robot

Strike text tool at http://adamvarga.com/strike/

Underline text tool at http://thejh.net/misc/unicode-underline

Combined all of the above tools at http://www.panix.com/~eli/unicode/convert.cgi?text=M%CC%B6%CC%B2%CC%B6i%CC%B6%CC%B2%CC%B6c%CC%B6%CC%B2%CC%B6h%CC%B6%CC%B2%CC%B6e%CC%B6%CC%B2%CC%B6a%CC%B6%CC%B2%CC%B6l%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6H%CC%B6%CC%B2%CC%B6a%CC%B6%CC%B2%CC%B6l%CC%B6%CC%B2%CC%B6l%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6e%CC%B6%CC%B2%CC%B6a%CC%B6%CC%B2%CC%B6t%CC%B6%CC%B2%CC%B6s%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6r%CC%B6%CC%B2%CC%B6u%CC%B6%CC%B2%CC%B6b%CC%B6%CC%B2%CC%B6b%CC%B6%CC%B2%CC%B6e%CC%B6%CC%B2%CC%B6r%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6f%CC%B6%CC%B2%CC%B6o%CC%B6%CC%B2%CC%B6r%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6s%CC%B6%CC%B2%CC%B6u%CC%B6%CC%B2%CC%B6p%CC%B6%CC%B2%CC%B6p%CC%B6%CC%B2%CC%B6e%CC%B6%CC%B2%CC%B6r%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6a%CC%B6%CC%B2%CC%B6n%CC%B6%CC%B2%CC%B6d%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6h%CC%B6%CC%B2%CC%B6a%CC%B6%CC%B2%CC%B6s%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6c%CC%B6%CC%B2%CC%B6h%CC%B6%CC%B2%CC%B6i%CC%B6%CC%B2%CC%B6c%CC%B6%CC%B2%CC%B6k%CC%B6%CC%B2%CC%B6e%CC%B6%CC%B2%CC%B6n%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6f%CC%B6%CC%B2%CC%B6o%CC%B6%CC%B2%CC%B6r%CC%B6%CC%B2%CC%B6+%CC%B6%CC%B2%CC%B6t%CC%B6%CC%B2%CC%B6i%CC%B6%CC%B2%CC%B6r%CC%B6%CC%B2%CC%B6e%CC%B6%CC%B2%CC%B6s%CC%B6%CC%B2%CC%B6.%CC%B6%CC%B2%CC%B6

Thanks to Akiva for the tip :)

Examples:

s̶t̶r̶i̶k̶e̶ ̶t̶e̶x̶t̶

U̲n̲d̲e̲r̲l̲i̲n̲e̲ ̲t̲e̲x̲t̲

Bold italic strike underline text: 𝙈̶̶̲𝙞̶̶̲𝙘̶̶̲𝙝̶̶̲𝙚̶̶̲𝙖̶̶̲𝙡̶̶̲ ̶̶̲𝙃̶̶̲𝙖̶̶̲𝙡̶̶̲𝙡̶̶̲ ̶̶̲𝙚̶̶̲𝙖̶̶̲𝙩̶̶̲𝙨̶̶̲ ̶̶̲𝙧̶̶̲𝙪̶̶̲𝙗̶̶̲𝙗̶̶̲𝙚̶̶̲𝙧̶̶̲ ̶̶̲𝙛̶̶̲𝙤̶̶̲𝙧̶̶̲ ̶̶̲𝙨̶̶̲𝙪̶̶̲𝙥̶̶̲𝙥̶̶̲𝙚̶̶̲𝙧̶̶̲ ̶̶̲𝙖̶̶̲𝙣̶̶̲𝙙̶̶̲ ̶̶̲𝙝̶̶̲𝙖̶̶̲𝙨̶̶̲ ̶̶̲𝙘̶̶̲𝙝̶̶̲𝙞̶̶̲𝙘̶̶̲𝙠̶̶̲𝙚̶̶̲𝙣̶̶̲ ̶̶̲𝙛̶̶̲𝙤̶̶̲𝙧̶̶̲ ̶̶̲𝙩̶̶̲𝙞̶̶̲𝙧̶̶̲𝙚̶̶̲𝙨̶̶̲.̶̶̲