Brother Tyler

I just tested the suggestion out and it isn't an option. Unless I'm missing something, rules only allow for one behavior, location, and milestone. I wasn't able to create a rule where a member was awarded a badge as a result of multiple behaviors (creating n1 topics and n2 calendar events).

Yes, we are considering a range of options. Having announcements was simply the most obvious solution (though perhaps not from a programming/developing perspective). We haven't ruled out any other options yet.

Just to be sure I understand, you're suggesting additional achievement rules and corresponding badges to emulate what we're trying to achieve with my two-track suggestion, with the criteria combining elements of other achievements, correct?

I'm curious about the announcement feature for Pages being "a huge mess." My community has just started using Pages (we call it "Articles") and, though we have very limited experience with it, it has been very helpful. Communities with considerably more Pages experience might have different experiences, however, so I'm interested. Your feed page suggestion is very interesting. One of the alternatives that we've been looking it is changing our landing page. Yes, pushing apps, especially things like Blogs and Pages, is on our radar. I'll look into your suggestions and seeing how we might implement them. Thanks for the feedback!

My community uses only 6 ranks, and while we don’t make a big deal of ranks (i.e., they don’t confer any privileges, permissions, or authority), we want them to mean something (i.e., there is some level of prestige from higher ranks). In keeping with the theme of our community (a wargame), our community ranks are based on titles (not ranks) within the game and there is a time/longevity component to them. Content and engagement are our main focus, naturally, and the more important element of all of this is the actual achievements that members earn; but we want the time/longevity implied by the ranks to be reflected to a degree. Under the current system, however, this is impossible. The only way to achieve more discrete control over ranks and to allow more flexibility is to create the option for achievement points to be assigned to different bins or tracks (I prefer “tracks”). While I could see how some communities might want to have any number of such tracks, more tracks means more complexity (especially for programmers) and a higher likelihood of things not working as envisioned. I’m only proposing the option for a second track. I’m not opposed to more being created, if it is feasible, but my community will only use a second track. I’ll illustrate this using my community’s concept. The default track is for all content and engagement while the optional track (in my community) would be used for longevity. Things are simple for the first three ranks. Members are automatically in the first rank when they join the community, with 0 achievement points. Members advance to the second rank with 2 achievement points, and to the third rank with 4 achievement points. Note that each achievement is worth 1 point, and we have achievements for as many things as possible to encourage participation. Our concept requires the second track only for the last ranks (and we are considering increasing the number of ranks by at least one). Our concept is that members can earn the fourth rank (“Veteran”) in one of two ways. If a member has a higher amount of content/engagement achievements, they can earn the rank at a lower longevity point. Conversely, they can earn the same rank with fewer content/engagement achievements, but it will take them longer. The fifth rank is similar (and any subsequent rank(s) would continue this progression). Mathematically, this looks something like: Content/Engagement Achievements = C Longevity Achievements = L Rank is subscripted number at either higher (↑) or lower (↓) value Rank 4 criteria IF C ≥ C4↑ AND L ≥ L4↓ OR IF C ≥ C4↓ AND L ≥ L4↑ THEN (rank 4) And each subsequent rank would be similar, with increasing values. We have explored trying to achieve something like this using the current single track system, but it is not possible.

I posted this idea in another topic, but it seems appropriate to bring it up here as a (hopefully) possible addition to v5. My community is Forum-centric, having begun over 25 years ago as a discussion forum and slowly evolving as software capabilities have grown. Despite the new capabilities, many members continue to use the discussion Forum feature to emulate those other capabilities, especially the Blogs. The Blog feature is very robust and is much better for blogs than pseudo-discussions. However, despite the advantages they offer to members, Blogs are woefully underutilized within my community. Blog users within the community have been discussing this disparity and the key recommendation we’ve come up with for increasing Blog visibility (and hopefully usage) is improving visibility of Blogs within the Forums. Ideally, we would like the publication of a blog entry to create an announcement topic similar to those created for the Articles feature. The solution we envision is that the blog entry author would make two selections as part of the blog entry creation process: Create a blog entry announcement topic (Y/N) If the above is selected… 2a. Create a new topic (blog entry author chooses the forum/sub-forum in which the announcement topic appears), or 2b. Add the announcement to an existing topic (from a dropdown list of announcement topics associated with their blog) Comment replies posted in either location (Forums and Blogs) would appear in both locations, just as the current Articles announcement discussions work. Our current workaround for this is to encourage members to create discussion topics that mirror their Blog entries, or which provide teasers of their blog content and link to the entries so that other members of the community might check the blogs. This requires additional work on the part of Blog authors, however, and most choose not to do that. Another option we’ve considered (but not really explored) is changing our landing page to give Blogs more prominence, possibly putting them on an equal footing with the Forums. This would be a significant paradigm shift for my community, however, and the majority of members would complain about the additional “work” [of clicking one more time to get to the Forums].

I’m following up on this since this was an idea that was recently suggested within my community (and I’m disheartened to hear that it’s not possible)… The suggestion within my community was that creating a blog entry would create an announcement topic similar to the Articles feature, allowing the blog author to choose whether or not to create such an announcement and where that announcement would appear (either a forum/sub-forum of their choice or an existing topic associated with their blog), with comment replies mirrored in both locations (Forums and Blogs). Since that’s not possible, however… Would it be possible for the publication of a blog entry to create a locked announcement topic in the forum/sub-forum (of the author’s choice), linking to the blog entry? The problem we have appears to be similar to that of Saskia’s community - the members are heavily focused on the [discussion] Forums and the lack of visibility of Blogs means that the Blogs, which are much more robust, are woefully underutilized. Having some way to pull members of the community into the Blogs without creating too much additional work for Blog authors would be extremely helpful.

We're going to decommission a -TESTINSTALL use of the license and move it to a different base URL. The site exists now after a lengthy upgade process. If we ask for the current TESTINSTALL license to be decommissioned, and then locate the document root into a new URL base, are the only changes we need to make in the conf_global.php? We don't need to re-upgrade (ie., "re-install") correct? That was a week-long slog through PHP and database processing we do not want to repeat. If all decommissioning means is: a) We "turn off" the TESTINSTALL site by making it offline (moving it out of the document root) b) Ask you release the license so we can re-commission it with a new base URL c) We revise the conf_global.php for the new base URL What exactly are the steps that allow us to avoid at all costs the "re-do" of the upgrade/install since it takes almost a week given the legacy data. Desired outcome: Current URL http://example.com License used FOO-TESTINSTALL Desired URL http://beta.example.com License used FOO-TESTINSTALL Without having to re-run the upgrade. We have a perfect DB and document root. We can edit simple files and database records, but a wholesale repeated upgrade is not feasible.