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