On Jul 31, 2018, at 7:47 AM, Richard Hipp <d...@sqlite.org> wrote:
> 
> *  Messages are organized into threads.

Will this work be reflected in part back into the ticketing system?  Few 
tickets in my repos get enough replies for this to be a noteworthy improvement 
over the existing unthreaded ticket replies, but I’ve seen epic tickets in 
bigger projects’ ticket/bug trackers that could benefit from threading.

> *  Messages can be edited, either by the user who originally posted
> the message, or by an administrator.

There’s another reason for tickets to become mini-forums: every now and then, 
I’ll create a ticket or add a comment to an existing ticket, rush through the 
Preview, and only after submitting it realize that it’s either incomplete or 
incorrect in some way.

I do realize the value in having stable conversations, but as long as old 
versions of each post are reasonably easy to access (e.g. by clicking on a 
“Edited on 2018-07-31 at 12:34:56” hyperlink added to an edited post) the 
chances of confusion due to replies referring to text that no longer exists 
should be reasonably well mitigated.

Some other fora have a timeout on editing, with the posts locking into a 
read-only mode after some time, but I don’t see the point in a DVCS-backed 
forum like Fossil.  We should no more allow that than auto-lock wiki articles.

> *  Because each message is an artifact, forum content syncs just like
> everything else.

Awesome.  This is just as it should be.  I’ll be using this in at least one 
Fossil-backed project as soon as I can figure out how to create a forum. :)

I’m expecting something under Admin, but it looks to be hidden functionality at 
the moment?  I don’t even see anything under “fossil help -w” that creates a 
new forum.  I started reading forum.c, but got distracted before figuring it 
out.

Incidentally, running the tip of forum-v2 against an existing repo causes this 
complaint:

warning: SQLITE_ERROR(1): no such table: forumpost in …noise noise… 

...when you hit the /forum URL.  Maybe there should be a CREATE TABLE IF NOT 
EXISTS in there somewhere?

Speaking of URLs, is /forume1 going to merge into /forumnew, and /forume2 into 
/forumedit?

> *  Email notification is available for new forum posts.  Currently,
> the alert emails contain a very brief synopsis of the post -
> essentially just the title.

I think the subject of the thread should be in the subject of the email.

This should also occur for other notification types:

- wiki: the article’s title
- ticket: the ticket’s title
- checkin: a Fossil-generated string, e.g. “Checkin [abcd1234]”

My vague understanding is that you have some kind of templating system when 
generating emails.  If you’re using a common template for all notifications, 
then you can use a generically-named variable like “topic” whose value changes 
according to the code path that leads to use of the template.

> This can be enhanced later to provide the
> complete text of the post, if that is seen as desirable.

It is desirable to me, at least.  

If I have the full post content, there’s a pretty good chance I won’t need to 
reply, which means I don’t need to make a trip back to the forum.  Logically, 
this must be the normal case for most users, most of the time, else threads 
would never die.

> *  Each forum message has a mimetype.  Currently supported mimetypes
> are text/plain, text/markdown, and text/x-fossil-wiki.  New mimetypes
> can be added later

The only other thing I’d like is a setting for default MIME type.  Per-repo 
would be fine with me, but there’s bonus points in it for you if you make it 
per-user. :)

> I hope to shut down the
> mailing lists and bring the forums all live within about a week.

I think this move will take roughly as long as the move to SHA-3, which as I 
recall had stragglers popping up months later.

I think it’s better to run the two in parallel with periodic warnings on each 
mailing list that the list will die soon.  Say, once a week for several months? 
 

If traffic drops off quickly enough, then a given mailing list can be shut down 
early, but that decision should be made on a per-list basis.  I suspect traffic 
will drop off fastest in the -dev lists, then next on the main fossil-users 
list, and that sqlite-users will take a long time to taper off if it’s allowed.

> please consider posting follow-ups there, as a test of the new forum system.

Will the existing content there live on?  With the temporary-looking URL and 
all of the test posts, I’m hesitant to post anything on the current forum that 
might have any useful life beyond this transition period.

Will the split between fossil-users and fossil-dev live on, or are you going to 
give up on that distinction with this move?  I’m not sure the -dev list 
provides much value to the Fossil project.  Maybe for SQLite it’s still a 
useful thing.
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev

Reply via email to