 So, I thought I'd put some things together, comparing just some thoughts and open this up. The majority of my experience with SharePoint has been SharePoint Workspace. Anybody know SharePoint Workspace used to be Groove. Used to be Groove was actually a very cool product. It was peer-to-peer, peer-to-peer, you could have it on your laptop and it would synchronize with all the other people in the background and you had a filing system right there on your laptop which you could then disconnect and you have access to it. I've worked somewhat with the regular SharePoint and I put just some notes here to sort of compare the two. Ah, we've got something is happening. Anyway, we've got two ways of thinking about MediaWiki. Two ways of thinking about MediaWiki. One is that we're going to use Pages and the other one is we're going to use Uploads. Then it's gone. So it's obviously whatever. So that one looks like it's more reliable. If you look at the page mechanism, you're able to edit online. It's immediately available. The changes are immediately available. So there are some advantages in currency. If you look at SharePoint, it's basically bringing up documents in there. So it's any duplication that's happened between documents is kind of out of sync. It's data at rest pretty much. Now that would be the same if you used the uploads. So if you used an upload, here is the major difference and it's a negative for MediaWiki, I think, unless I'm missing something. The SharePoint comes already with the tools to be able to organize by folder and organize by an office administrator. That's it. And so you can set all the folder structures up the way you want it. And it's immediately available for them to do the organization. But MediaWiki right out of the box really has no organization mechanism for the indexes to the documents, whether it's a direct pointer or you want to put them into a folder or an organization structure. Now, I believe it could be built. I was starting to play around with this the other day. I said, could I actually build a killer filing system on top of this? Use all the extensions that I wanted to, etc. And I actually started to have some problems that I couldn't get through the file page to find the property, which would link me to the media itself. And since that property seems to be missing from the file page, I couldn't actually construct the index, which would take me directly to the media document. So I didn't really pursue this, but I think it could be a project that could be embarked on to say, given out of the box tool. And we talked about this a little bit earlier, not a platform, but a tool with page form support for an administrator to be able to set up folder structures. And the index is needed to do the same function. Yes, it could go in both. It's just an index, it's just an index. When you actually look at the way that it, I'm sorry, I can't hear. Yeah, it's whatever collection you want. But you've got to set it up and then show it to the user in terms. So they know how to navigate to the right, whether you talk about a folder or an index, it doesn't matter. But I think something could be built that would then show the capability of doing this in the same way that the administrator can set it up with the structures that they want the office to administrate it. In Media Wiki, we've got finer granularity depending on what extensions you're going to use. We've got fields, obviously. We've got sub-objects and we've got reporting structures, which are much, much more powerful. And then we come back to the security question. And the SharePoints basically got security by workspace. So you can actually divvy it up into different workspaces and give people permissions to get access into those workspaces within the SharePoint site. So it does have some level of granularity. It's not much more than that. But and we're still at the security question of how do you give access to portions of the Wiki to name people? And that was kind of my summary of where I saw that the differences between the two. I think the potential is great and I think that Media Wiki could be shown to do this function and give an administrator the ability to be able to set it up. I don't think I have it up here. I don't know whether. So I think this is a topic that comes up at work all the time. So this is a great topic. As far as organization by folders, so you're talking about, well, you might be talking about also using categories. But is what you're talking about as far as getting a structure different than what drill down currently exists is? So that's kind of how I understood of what you're talking about, is just visualizing the way you're categorizing your Media Wiki data. Well, I think it's more a manual positioning. These are all the things associated with this aspect of this project. And it's a manual placing, one done by the administrator, more than anything. Yeah, because we, I mean, so our issue that we run into and why I don't think the SharePoint organization by folder is an advantage of it, but more of a disadvantage of it, is a lot that we've been struggling with. And why we've moved more and more of our data to is that people's understanding of how data is related to something changes over time, right? Depending on what you're using on it. I think Lex gave like a really good talk on this a couple of years ago about viewing the Eiffel Tower from different directions and stuff. But in our instance, we had for years space shuttle flights that went up and they assembled the space station. So people thought of our data by space shuttle flight, all right. Now, since then, we've stopped with assembly and we've been real time ops. And people who've worked there for almost a decade now, never were involved in those space shuttle flights for newer people who arrived. So they don't relate that data to flights now. They relate it to hardware and to different dates that things happened. And so when you have, and we, so we had all this data is in different folders by flights, but people don't instinctively think to go and search in that way. So they're missing some of the data that's there. And because of that, they're also duke, when they find that data, they're dukelicating in a different place because they don't know it already exists in one. So it's a huge thing that we've seen as advantage of MediaWikis, be able to link things from different directions, basically. You can get to the same piece of data from a lot of different locations. I think there's advantage. I think it's in the perspective of the users though and what they used to doing and they're still back in the physical filing system mentality. And they're looking for that, they're looking for that folder structure the same way as it's in Windows and the same way it's in Unix. And it's a hierarchical structure. That's the way they understand it. But I mean, I totally agree that there's better ways of doing it. I think this is actually really interesting in a way that with the folder structure, this is the most similar of the enterprise use cases I've heard here to something that a Wikimedia project actually does in the form of Commons, which is where Wikimedia puts its images basically. And they're mostly arranged in a somewhat dysfunctional category tree, which in essence is basically a folder hierarchy. Like you have a category named dogs and then there's a subcategory of dogs in parks. I don't know. There's a bunch of things. Domesticated elements. Yeah, there's like every way you can imagine. So it's all organized into a folder. So this kind of approach to full does exist inside MediaWiki even without any fancy extensions. I'm not sure how well it works, but I think we do have that implemented more or less. Maybe what I'm suggesting is we need some demonstrations of how to do that, maybe rather than build something tomorrow. File name space is flat, but the category name space is very hierarchical. And what the second? The category name space is very hierarchical. Oh yeah, the category. So you could assign the categories and make the filing. I think it just has to be demonstrated. I think it can be built. The capabilities are there in the platform. It's just show you what. I'd like to see that, yeah. So I haven't seen that, but yeah, you can use the category structure. I think it's part of and it can be set up by an administrator. Yeah, no, right. But when you're setting up category structures, you say, yeah. You can do that. Yeah. Yeah, yeah. So I need to query it up. And you can query it by organization or by folder or by some tags that you have or organize one dog within an orange or yellow flower around the neck. You will find it. Now here's the question though. You can do lots of things. Can an office administrator do that? And you're OK with that. Right, right, right. So there's a file naming constraint. And that's fine. Everything has a name. So yeah, I'd like to see that tomorrow. I think it's the ease of use from an office administrator that I'd like to see that. Anyway, that was, I guess that's one's gone. One comment I was just going to make that Darren likes to talk about this a lot as well is one of the things that SharePoint is supposed to be optimized to do is to version and edit Microsoft Excel Word PowerPoint products and track changes. Yet how many people at least definitely happens in our office and probably in New York too, they're just emailing out copies or they're saying, please email me your edits to the Word document and I'll put them in myself. And they just completely ignore the baked in versioning capability of SharePoint. And I think that, from my perspective, is one of the things that SharePoint is not even doing what its core capability is supposed to be well. It's not intuitive to the users. The other thing is that so many, and I realize I'm speaking to the choir, but how many items are only put into Excel documents, Word documents and PowerPoints because that's what people are familiar with. And even though it's only ever gonna be viewed in an electronic only format, they're just sticking to those products because the company has a SharePoint and it's in a Microsoft ecosystem. And then the third part of SharePoint versus Wiki is when people will say, well, let's just do a SharePoint Wiki. And so I don't think you touched on that in your comparison. Well, I was trying not to do that. Yeah. If you emulate with an uploads, that's what we're basically saying. That I think that you're gonna get, you're gonna have something that looks the same and has all the same disadvantages. Yeah, I was just gonna go to say that almost the fundamental test there is if a basic user goes to any, any Wiki page, that whole, every page is page one, they should be able to edit and make a change instantly. Whereas if a page isn't properly configured, or even a SharePoint Wiki page if it's not properly configured, they're still not gonna be able to edit it intuitively right away. So that's the third fundamental difference I see. All right. The other reason that we have, people who wanna stick to SharePoint for certain reasons is for dual editing, right? So SharePoint's main thing is, you can live dual edit Microsoft Word documents between each other and see what each other are doing, add comments, go through. And there are definitely cases in our work and I'm imagining other enterprise instances where you wanna be able to have that live back and forth that you can visually see. I know you can edit a page at the same time and if there's conflicts it will try to work them out but that's not the same as literally being able to actively see what's going on. So. What are each of your pages for? All down. With real-time collaborative editing we don't really have an answer to that. They're... Yeah. We have a lot of crappy halfway answers. It's not exactly halfway. Yeah. I think even those could be made a lot better than what we do currently like. When you have an edit conflict in Git it's not anywhere near as miserable as on Wiki. But real-time collaborative editing would be a whole other cool thing. Well I don't actually edit Wikipedia so I don't know. I think they do get edit conflicts and they just deal with it. Generally you only get an edit conflict if you're editing the same paragraph because we run it through GNU Diff3 which is a tool for merging source code so they assume new lines. It's like the break of a sentence. So instead that turns kind of into paragraphs when you're editing Wiki text. But yeah, mostly they just deal with it. I think Wikipedia Deutschland had a thing to make it slightly better. And I know I think Visual Editor has some like very long-term plans of looking into it someday. There's a demo given at the... Being a hackathon or something like that I think there might be something like MediaWiki.org, some real-time collaborative editing. So that's all. And someone at one point, someone had a etherpad text area for... What's that? The smart mark? No, that was my doppelganger mark. Oh, not all of us have MAHs as our initials and we're pretty special. Although there are two of us. Anyway, does anybody else have a comment? If not, we can go...