Ticket #211 (new enhancement)

Opened 2 years ago

Last modified 2 years ago

New wiki / bugtrackin system?

Reported by: augustin Owned by:
Priority: major Milestone: 1.x
Component: documentation Version: trunk
Keywords: web site Cc:



mr_lundis wrote:

It indeed seems like wiki editing is locked for newly registered people, and ironically I don't have permission to change the permissions. I'd guess that page editing was turned off after spam issues (trac doesn't even require email verification for new accounts.)

What I can do is to update the pages after your suggestions, but that just won't work in the long run.

I'm looking in to alternate solutions for documentation management, like GitHub wikis or pages, other third party wikis, or setting up a new git repo/branch that syncs with our current server on push (much like GH pages, but hosted by us)...

Do you have any suggestions?

Actually, I do :)

I think the current set up (double login: forum + trac) is a major weakness. People who register in the forum will never register here... and therefore never contribute anything to the wiki.

Also, all the forum posts really belong to the bug tracker: either the forum topic is about a bug (-> bug tracker), a feature request (-> bug tracker) or a support request (= deficiency of the documentation -> bug tracker).

Actually, the place where this discussion started is a good example. Most people would have posted this in the forum:  https://trac.wymeditor.org/trac/ticket/208 But by posting in the bug tracker, we've been able to identify a useability problem that can be fixed in svn.

A web site with integrated wiki + bug tracker and without a forum is a must.

My first idea was to propose to close the forum and exclusively use trac. But since the sentiment appears to be to move away from trac, may I suggest a fully-featured Drupal web site?

I am a Drupal module developer, and I know the insides of Drupal quite well. The basic set up (drupal bug tracker + drupal wiki) is easy to do. After that, I would be able to help you customize things where it is required.

I don't know about trac, but with Drupal it's easy to create several projects: one for the wymeditor software itself, one about the wiki (documentation), one about the wymeditor.org web site....

Also, you mention git. I am not sure if you imply you're thinking about moving from svn to git. In any case, the whole Drupal project is moving to git soon, so we would be well served if wymeditor does so too. But it's not necessary. Up to you.

I don't know who actually is the project leader. But if he's interested enough, I can set up a demo Drupal-based web site for wymeditor.

I don't know if this is at all what mr_lundis had in mind above. I open this ticket for discussion.

Change History

comment:1 Changed 2 years ago by mr_lundis

The current solution with different accounts on trac and the forum is indeed problematic. We have discussed this internally (me and jfh) and we have looked at several different solutions.

Jean-François Hovinne (aka jfh) is one of the founders of the WYMeditor project, and the one running the server on which everything of this is hosted. He is rather inactive today due to personal reasons.

As of now a move to Github is (slowly) on it's way, as it allows for really easy contribution and there is a strong community. How we'll manage issue tracking, documentation and discussions (forum/mailing lists/etc) is still rather open...

Github provides elementary issue tracking and an equally crude wiki, but no "discussion management." So pairing Github with another solution would seem as the best choice.

We have looked at is Redmine + Github, which would provide essentially everything we need. The same is true for Assembla + Github as well, although that's a hosted solution. However, both of these would result in several different development sites which we want to avoid. Of the two Redmine is most easily integrated with the main site.

We could also stick to the tools provided by Github and use an external forum like Vanilla, phpBB (currently used) or Zoho Discussions (hosted, used by the jQuery project). These could also rather easily be integrated into the main site.

What's important if we end up with several different sites is to allow people so sign in with the same account everywhere, for example trough OpenID, and preferably only once. A separate account would still be needed for Github though...

How a Drupal based solution would compare to this is interesting. Also jfh is doing some Drupal development, which is good from a future maintenance perspective.

You suggested dropping the forum completely, but I don't really believe in that. I's true that most topics eventually end up here somewhere, but that's often a result of an earlier discussion. Take this ticket for example, in my opinion this discussion would be better of on the forum, allowing more people to contribute. Also, some people feel uncomfortable with posting issues at bug trackers directly, having only a bug/issue tracker would shut them out.

What's problematic is when there's no clear distinction between where discussions take place and issues are tracked. You could argue that there should be no distinction, but having to browse through long discussions to find the actual issue and the current state of it is far from ideal. Keeping discussions and real issues apart makes for easier development, but that's just my personal opinion.




 http://vanillaforums.org/ and

Zoho Discussions:

comment:2 Changed 2 years ago by weswinham

I am personally very fond of using github for wiki, ticket tracking and source control. I've set up a github mirror of the wymeditor svn repo already that syncs with SVN every 15 minutes via cron, and it was pretty straight forward if keeping SVN compatibility is a major goal.

For support/forums, I'm less particular, but I do see many of the projects I use having good success with google groups. I don't see anything wrong with the current wymeditor forums though.

Note: See TracTickets for help on using tickets.