Issue #1735 wontfix

Integrate wiki with source code repository

created an issue

Integrating the project's wiki with its source code repository means to have a folder in the repo which contains the docs. The user could then declare here on BitBucket which one of the repo's folders should be used as wiki.

This would allow the documentation to grow along with the source code instead of both evolving separately from each other when having a repository for each of them.

Comments (6)

  1. codethief reporter

    Seriously Jesper, what *are* you going to "fix"? You wontfix-closed all feature proposals I have been hoping for for more than just a few months… :( On a sidenote: This feature (wiki->source integration) is the reason I haven't used BitBucket on a regular basis for more than a year. I was constantly waiting for it.

  2. Jesper Noehr


    I'm sorry you don't agree with the decision not to do this. We're cleaning up the issue tracker from the bottom to the top, so we can actually stay on top of it (I'm sure you've noticed we haven't for the longest time.)

    We're going through each issue, discussing it, and some of them we decide we don't want to do. This is one of them. I'd be happy to hear about the other ones you're unhappy with us closing.

    If you'd like to know why we're not doing this in specific, it's because:

    • Editing the wiki in a repository that's also used for code can get messy, real quick. We're already seeing a bunch of people clone, manipulate and push wiki's back to us, with multiple heads, etc. That confuses the hell out of the system.
    • Adding more options/checkboxes to repositories is not something we want to do. There are already too many things you can configure (IMHO), and we need less, not more.
    • Having the wiki in the repository is just not a very big win.
    • No one has really expressed an interest in this.

    If I'm missing something here, please tell me.

    We're choosing to focus on other aspects of how to improve Bitbucket, and hopefully you'll come to like those things. Until then, we have to choose what we will do and what we won't do.

  3. codethief reporter

    First of all, I'm sorry if I have been a bit rude in my previous comment.

    The thing which is constantly bugging me is that source and documentation are completely disconnected. If I'd like to go back in time and have a look at the source at time x, I'd always have to do the same process for the wiki repo. Ok, this is something which isn't done often. Another point is that integrating the wiki with the code would somewhat force developers (at least us) to always keep the full-text project documentation (not source code ) up-to-date. If the wiki is outside the source, I'm always tempted to neglect the docs ("I'll update them later…"). In contrast to that, if it's inside I always think of it as something I simply *have* to do before committing. Also, it helps me to keep track of…

    1. the project's progress (what exact idea led to that code change?)
    2. my colleagues' fundamental changes to their forked projects, i.e. new ideas they have and want to try out et cetera. If their changes get finally pushed into the main repo, we also have to merge the wikis (which means downloading the main one, pulling their changes, and pushing it all back). So, actually there are always two repositories every developer has to take care of.

    Maybe our case is a special one here. I actually don't see the other guys on the team regularly (let's say rarely) which makes it hard to explain ideas to the others thoroughly if you can't agree on a definite time to skype or chat. … which is why we use the wiki for describing new thoughts, while using mails to discuss. This is why, for us, it's extremely important that source and documentation / concept are linked.

    Finally, I'd like to comment on your concerns:

    1. I don't really get what exactly should confuse the system. I mean you're already doing the same thing for source code. In how far is it more complicated if you do it for texts?
    2. In my opinion the number of options hasn't changed that much during the last years. I don't say you should include every tiny option. Just the things which are practical. :)
    3. See above.
    4. You have a point. On the other hand – how difficult would it be to implement it? As for the wiki, you're already dealing with repository stuff. Couldn't you just change the reference, which is used by the system to access the wiki repo, to the source repo?

    I'd be happy to hear about the other ones you're unhappy with us closing.

    For example the one asking for different wiki styles support (haven't found it by searching). In our case reST support would be perfect. We basically use it because that way we don't need to separate source and wiki as we can easily edit the docs in our code editor (since it's easily readable). ;)

    P.S.: This text editor is buggy as hell (using Firefox 3.6.13 on Ubuntu). When it has lost focus and I click on it again to continue typing, the cursor always jumps to the top (so I have to scroll back down) and becomes invisible. (I dont know if that's just a bug in Firefox. It's not the first time I experience this (happens every 2 months or so) though it's the first time it appears regularly (every time the textarea gets the focus). It's especially annoying when clicking on one of those styling buttons. The characters are also always inserted at the end of the text

  4. Log in to comment