Done with TeamGantt
Twproject was a mess for me to use. But this is not so bad.
Tentative Gantt for MENA YP: https://drive.google.com/open?id=0B_vWawrKpTaFRjF5UE9QdEFINkU
1 Like
Confused
@Matthias , now I got confused. Is it Twproject or OpenProject? Do I have to do it or will you?
One thing I am sure of: doing manual beautification is overkill. The good thing about GanttProject etc. is that they draw the Gantt autoatically from a database of activities. This is essential, because you keep tweaking activities as you build your proposal or plan, but you do not want to leave the Gantt to the last minute. “Beautiful” in this context only means “tidy, legible”.
You, OpenProject 
@Alberto , you should do it, using OpenProject (because that’s all we have up and running right now). I can still care for PDF conversion, or similar, if there’s any need.
The Twproject Gantt section is just there to inform our future software development goals (SDGs). I almost confused myself though. So many alternatives for Gantt charts, and none of them truly great 
Thredded or Discourse
They don’t seem to be “threaded” format (a la Reddit) but rather more linear. BoingBoing uses Discourse: https://bbs.boingboing.net/
Thredded looks a lot simpler.
Do you have a preference with these Matt? I think Discourse could be made to present better. I don’t know which one of them is easier to find where the action is if you don’t have much of a patciular agenda on any given day but still want to converse. (A weakness of ER as it is today).
Discourse, except if too hard to extend
Regarding favourites, Discourse is clearly the more sophisticated one. It has its own approach to threaded comments (relevant to @Alberto ). To me, it seems compatible for our conversation analysis needs (where we want “comment a is reply to comment b” relations). Even better, it also offers using quotations, and seems to keep the semantics intact (knowing where the quotation comes from). So with multiple quotations in one reply, we could (in the future) decuct relations like “comment a is reply to comments b, c, d”.
The only reason not to choose Discourse would be if it offers way more features than we need (“the Drupal fallacy”), which would make it too complex to integrate our custom code with reasonable effort.
1 Like
Discourse installation ready to test
Well then, this is for the alpha tester team, esp.: @Alberto , @Noemi , @johncoate , @Nadia . Also Patrick of course (but no expectations, just if you like to have a look). With our developer Daniel, we have set up a quick demo installation of (not-yet-customized) Discourse here: https://edgeryders.eu/. (Edit: Login credentials are in the admin group here. Also, remember that the demo installation for testing things out has now switched to https://staging.edgeryders.eu/ – please do not change stuff on edgeryders.eu for the time being.)
This gives you admin privileges, so you can also access the admin backend from the top right. Happy playing around! All content there will be erased again, so move and create and delete whatever you want. We have to answer the following questions in order to move forward with the development. It’s all about mapping our current data structures to those of Discourse:
- How to implement challenges? Our current proposal: Challenges become categories. This is nice, because unlike tags, categories are visible in the Hamburger menu. Alternative proposal: Challenges become Groups in Discourse. In Discourse, categories are presented as the typical "forums / boards" of discussion software, so this seems the closest match for our challenges.
- How to implement channels? Channels are the multi-select field in the challenge response form, then is presented like this. Proposal: channels become tags. That allows one thread to belong to multiple channels (like now). So it's better than using categories, since a thread only belongs to one category in Discourse. Edit: However if we are ok with only importing one channel value per post, we can also use categories. Categories can be used to implement challenges and channels at the same time, as they are hiearchical.
- How to implement supporters / multiplicators / collaborators? These are fields in the challenge response form, allowing folksonomy input of multiple tags per field. Proposal: these fields become tags. Tag values can be free-form like now, or pre-defined.
- How to implement challenge chains / projects? This is what keeps challenges grouped together, and also we need it as a data structure to keep content of different projects separate enough for analysis etc..
No proposal yet. Maybe also tags, with some sort of auto-tagging? Like: Everything posted to this challenge will be tagged "WB MENA Platform".Edit: A proposal is to implement this as parent categories, with all the challenges of a project being the child categories. After a project ended, parent categories may be dissolved, and challenge categories assigned to a parent category "Completed Challenges".
Feedback from own tests
Just a collection of observations from my own testing:
- I found a feature that allows registered users to post anonymously. This solves the spam problem (as users can only post after login) and also the operational security problem (as the platform does not record who posted when posting in anonymous mode). Like many of the innovative features in Discourse, this one seems to require a warped brain to invent. I like it.
- There are per-category access rights for "See & Reply" only. Applying these seems perfect for archiving challenges. People who find these old threads can still add their replies, so the discussion keeps being latently active and useful, but people cannot create new topics (challenge responses in our terms) in these categories.
- Heart buttons for potential PayCoupons integration. I just had this crazy idea: for an entrepreneurial community with a strong P2P spirit, it makes complete sense that "Likes" for valuable content are not just a digital event, but are worth something. Namely, if users go to their settings and connect their PayCoupons account, each like will be worth a donation of a standard value that the user can configure (but similar to Flattr). After clicking the "Heart" button to like something in Discourse, a field may appear where the user can increase the donation amount for this liking, but that would be optional. For users who do not connect their PayCoupons account, liking works as normal. For users who receive PayCoupons-enabled likes but have no PayCoupons account yet: they will receive the PayCoupons transfers automatically once they create and connect their PayCoupons account. In addition, all users would have fields in their profile to tell (in short) what services they offer for PayCoupons.
Tiger team testing
- Discourse takes the idea of a "ladder" of user levels from web forums of the 1990s: https://meta.discourse.org/t/what-do-user-trust-levels-do/4924/2 . I am not too happy about the idea of automatic demotion of users (from level 3 up).
- Also badges: are we sure about all this gamification? I am more sympathetic towards a relaxed approach to online communities.
- I don't understand, @Matthias : are "categories" the same thing as "boards"?
That’s all for now.
categories = boards
- Yes, categories are conceptually the same as boards. Every thread (=topic in Discourse speak) belongs to exactly one category, and categories are used as the main structuring element in Discourse. I think they name it "catagories" only because posts from all categories appears in the same list on the homepage. It's not like "being in a board / sub-forum", where you could then see only the content of that board / sub-forum.
- We can of course disable the whole badges system (it's in the admin settings). I'd also recommend we don't go down that gamification path.
- Likewise, we may want to not use trust levels the way they are intended to. We might want users to start at level 1 or 2 instead, and disable automatic demotion of level 3 users by setting leader_promotion_min_duration to infinity (setting is mentioned here).
So there is some flexibility in the Discourse settings to adjust how it works, and I hope it will be enough for us. What I like (a lot) about its UI, after an hour of adjustment, is that all the content is accessible from the homepage. What you get there is a simple query interface to see the posts you are interested in. No more diggingin sub-forums / groups / projects etc. without knowing if you have seen it all or if there is more.
Suggested topics
Is there any logic to it? It looks random to me which makes it clutter.
Visual summary of conversation so far as UX flow?
Hi John, it feels like we are at risk of getting lost in tech details of the new platform at the cost of having a coherent, actionable proposal for how the platform should look (Ux, IA and Interface design). The differences in our respective communication patterns are not helping.
I for one am having a really hard time integrating all the above into a coherent set of specifications and actionable instructions. In part it’s because my cognitive bandwidth focused on other tasks (e.g. me: business development, client relationships and sales).
You are the most experienced out of us all - can you help?
Discourse as part of the platform
Am I correct that we’re looking at the details of how Discourse works, but that is all a subset of The Platform, which will be developed using the Ruby/Rails CMS?
If that is the case then I am curious if Discourse can weave in with the other content on the Platform - something today’s ER site does well. Or if you have to stay within Discourse if you want to converse with people.
To the larger question, it is my understanding that we have in our proposal for MENA YP that we will start out right here on “ER classic” and migrate over to a new Ruby-based platform once we get it set up. Am I right?
If so, then what do we want the new site to do that we can’t do now? Is it not a matter of how much functionality but rather functionality that is both easier to maintain and manage as well as easier for the user to understand? I am pretty sure that is a main driver of going away from Drupal, based on what I remember Matt saying.
It seems like we’re a little stuck in nomencalture. And for me, the ER site already has a lot of that. Posts, wikis, blogs, events, challenges, stories, projects, channels and others I am surely leaving out. My first question is do we want to retain and present that kind of complexity to the MENA YP people and do we want the Platform we develop to have all those choices presented in the farily simultanous way that we do now? One has to sort of wrestle with the ER platform for awhile to get it, to really grasp it. I find that it rewards people who come in and don’t know that much about what is going on yet (we help with “start here” and “tell your story” and “what’s new” etc), and real power users who have worked out some of their own efficiencies on how to get work done using the site. I wind up leaving a ton of tabs open and going back to them, often wondering, “what’s this one about again?”
So now we have Discourse that wants to call certain things by certain names. Thus, more nomencalture discussion over what we call something. But really, it’s how do we want to present the site and its tools to people? We have worked on the UI of the current site and as I recall it is not fully to where you want it to be. We don’t want to reinvent the wheel here if we want to keep good design and ideas, but it is also an opportunity to change things. But that will be within the boundaries of the Ruby/Rails CMS environment and its templates and added applications. I set up and ran a Joomla site for the radio station and I don’t think it is terribly different from Ruby as a manageable CMS system.
So do you want us to come up with a visual map of what it is we want and see if we can get Ruby/Rails to do it?
1 Like
@johncoate , I’ll (try to) answer below 
You are right that Discourse will provide a subset of the platform’s features (let’s say 80-90%). Discourse would be our new base software and Ruby on Rails our new programming language, just how the current platform uses Drupal as a base software and PHP as a programming language.
All conversation would happen in Discourse (forum style) and Matrix (chat style). About the if and how of the Matrix integration I am not yet clear … it may be possible to also use Discourse itself for chat-style communication if it supports realtime updates of threads (“topics” in Discourse speak). Anyway, there is no real need to weave in with the other content of the platform, since all existing content (incl. wikis, posts, challenge responses etc.) will be imported into Discourse itself, into a few static pages (“Abouts us”, “Legals” etc.). I am not yet clear about where to put the Edgeryders Admin group content in the future: either into Open Project, or into a private board in Discourse.
That is correct, that’s the original plan. (Daniel hinted at the possibility to do the migration earlier, namely in time for the MENA Youth Platform’s prototype. The time plan for that prototype would be 2017-07-15 (one month after contract start). To be discussed.)
Right Drupal is a CMS for publishing content, it is not good at anything related to interaction, and it is not a specialized conversation software. When you click through the Discourse admin backend (login credentials see above) you’ll see how this is much more advanced software for managing conversations. It’s a pity Discourse was not around in late 2012 …
Exactly my concerns as well. The Discourse based platform should be much simpler to navigate and understand. We will not have all these different types of content there, they are largely a legacy of past experiments before settling on the challenge-and-response format. The beauty of Discourse, which will be the main interface, is that all functionality and all threads are accessible from the homepage. No need to navigate to some hidden sub-forums (like “Projects” on the current Drupal site) to see everything. Just use the filters on the homepage. In addition there are some static pages for “About us”, “Legals” etc., all of which would be accessible from the main menu (which we’ll add to Discourse). And that’s it.
All existing content will be imported into Discourse boards (“categories” in Discourse) and threads (“topics” in Discourse), and they will be consistently called “challenges” and “responses”, respectively. Actually, I am still looking for a better wording than this. “Challenges” and “stories” maybe? Do you have an idea? I think it’s quite important to get these two words right, as they will be used throughout the software, and should evoke the right connotations. For example, in the light of the Open Village vision, people should be aware that it is ok to write content about open source developments / inventions created by others, if it answers to the “challenge”.
Ruby on Rails is not a CMS, but a programming language. So that’s quite different from a CMS. I intentionally don’t want a general-purpose CMS as base software anymore, since CMSs suck at interaction, and are not optimized to handle online dialogue. So beyond Discourse (and a Matrix chat client should we add that), there are no pre-defined features as “boundaries”. We can add whatever features we want by programming them in Ruby, and that is much faster than extending Drupal with self-developed modules written in PHP. However, as always, if we can get around programming something, we take that opportunity. So the question is rather “How can we map the features we want to what Discourse provides?”. Plus, of course, “What features do we have to write in Ruby because Discourse does not provide them?”. I provided an outline of a potential answer to the first question above, and any feedback and counterproposals would involve digging through the Discourse backend. In addition, everyone is welcome to propose essential features to add that Discourse does not have. You can use a visual map for that, sure.
Badges and levels of trust
I vote no on that stuff. I can see if for certain other situations but not ours. Unless we want to designate people who are hosts of various areas/domains/categories - whatever wer wind of calling it. But otherwise I don’t think overt merit systems work with out way of doing things.
2 Likes
Agree about badges / trust levels
I’ll disable badges on the staging website, and about trust levels … we may use them in a rudimentary form to prevent spamming, but not as a merit system. Will have to see how to configure that.
Gamification failed in Edgeryders
We experimented with gamification in the very first Edgeryders platform (Drupal 6), but those features fell completely flat. I am not sure how directly this applies to the badge system here, but we should remember it.
StackOverflow uses badges, and so does Khan Academy. I admit I do not pay attention to the badges, in the sense that I don’t change my behaviour to unlock more of them, but I do get a nice rush when I unlock them. And as for user levels: recently my reputation on StackOverflow reached the level where I can upvote or downvote an answer. And that was very useful, because now I can compensate people helping me by increasing their reputation.
Maybe user levels are useful at the very bottom, to prevent very early users from breaking stuff, but probably not above that. And badges may be a good thing if they come as little surprises in your normal workflow.
1 Like
There may be a connection 
The company behind Discourse was founded by one of the founders of Stack Overflow / Stack Exchange (who dropped out later to “revolutionize online dialogue” with Discourse). So there is probably a direct connection why Discourse has this badging and user level system.
On Stack Overflow, I don’t care about badges at all. It’s just too much for me to understand what each badge is and what I’d have to do to get it. I’m not interested that much in the game. But I care about reputation numbers there. Having these little green “+10” or “+20” reputation change notes in the top bar when visiting there again is nice. They almost look like money notes
This is what a busy Discourse site looks like
The site is a blog (a sophisticated one, but still a blog), a BBS and a store. Not complicated. They handle a ton of traffic.
It is noteworthy that in their case their main page - the blog - does not have an obvious link to the BBS. They drive their conversational traffic through their blog posts and the comments therein. You can however go to their Discourse BBSpage as their main page (if you find it and bookmark it) and go backwards to their blog stuff. I’m sure it was an interesting conversation they had deciding to do it that way.
upvoting = likes
primitive upvoting
Today’s Interface -> ER in Discourse
Edgeryders has a complex nomenclature with terms that point to pages that don’t differ very much: post, blog, wiki are pretty much the same thing in practice. A written statement followed by the same comment options. So having three names for nearly the same thing is overly complicated.
Discourse is much simpler. It breaks down into Categories - Topics - Replies
I presume categories here would be the various projects.