#364 discourse integration
Closed 7 months ago by msuchy. Opened 7 months ago by msuchy.
copr/ msuchy/copr discourse  into  master

@@ -119,3 +119,7 @@ 

  

  NEWS_URL = "https://fedora-copr.github.io/"

  NEWS_FEED_URL = "https://fedora-copr.github.io/feed.xml"

+ 

+ # enable Discourse integration

+ ENABLE_DISCUSSION = False

+ # DISCOURSE_URL = "https://discussion.fedoraproject.org/"

@@ -114,3 +114,7 @@ 

  #   # Description sometimes put into template to make clear what we point to

  #   'user_desc': 'FAS account'

  # }

+ 

+ # enable Discourse integration

+ ENABLE_DISCUSSION = False

+ # DISCOURSE_URL = "https://discussion.fedoraproject.org/"

@@ -63,3 +63,7 @@ 

  

  # Hide page parts not relevant to this Copr instance:

  # LAYOUT_OVERVIEW_HIDE_QUICK_ENABLE = False

+ 

+ # enable Discourse integration

+ ENABLE_DISCUSSION = False

+ # DISCOURSE_URL = "https://discussion.fedoraproject.org/"

@@ -71,6 +71,8 @@ 

      NEWS_URL = "https://fedora-copr.github.io/"

      NEWS_FEED_URL = "https://fedora-copr.github.io/feed.xml"

  

+     ENABLE_DISCUSSION = False

+     DISCOURSE_URL = ''

  

  class ProductionConfig(Config):

      DEBUG = False

@@ -81,6 +81,24 @@ 

        {% endfor %}

      </ul>

      {% endif %}

+ 

+     {% if config.ENABLE_DISCUSSION %}

+     {% if config.DISCOURSE_URL %}

+     <div id='discourse-comments'></div>

+ 

+     <script type="text/javascript">

+       DiscourseEmbed = { discourseUrl: '{{ config.DISCUSSION_URL }}',

+                          discourseEmbedUrl: '{{ copr_url('coprs_ns.copr_detail', copr, _external=True) }}' };

+ 

+       (function() {

+         var d = document.createElement('script'); d.type = 'text/javascript'; d.async = true;

+         d.src = DiscourseEmbed.discourseUrl + 'javascripts/embed.js';

+         (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d);

+       })();

+     </script>

+     {% endif %}

+     {% endif %}

+ 

    </div>

    <div class="col-sm-4 col-md-3">

      <br>

@@ -213,4 +231,5 @@ 

  </script>

  {% endfor %}

  

+ 

  {% endblock %}

It is enabled on copr-fe-dev where you can see it live.

Shouldn't there be some protection against misuse? How the discourse server knows that we are not chating and that we really are copr service?

Sorry, it's neither implemented in diqus.

We could have only one argument, by default set to None. Maybe something like FEDORA_DISCUSSION = URL (or None) would be preferred, so we can implement others in future.

It is enabled on copr-fe-dev where you can see it live.

I don't see it e.g. on https://copr-fe-dev.cloud.fedoraproject.org/coprs/g/copr/flock/

I will give more comments when I can check it out.

I just wanted to write it too; even though the code is there, the javascript seems to render nothing.

I'm curious whether we could make the discussion somehow better paired with particular copr overview page ... so even if we changed copr hostname or url layout, everything would be well connected with relevant discussion.

I missed ' here. The code on copr-fe-dev is altered. I will update this PR in a moment.

rebased onto f1335438b0c7da9192e95e1ffcc09f1aaf64b623

7 months ago

rebased onto a5b6d73

7 months ago

updated

Cool, thanks. I am still interested if we can enable answering directly in the embedded mode. This is something we definitely want.

Cool, thanks. I am still interested if we can enable answering directly in the embedded mode. This is something we definitely want.

It is not possible. As stated here:
https://meta.discourse.org/t/embedding-discourse-comments-via-javascript/31963

One important thing to note with this setup is that users have to navigate to your forum to post replies. This is intentional, as we feel that the posting interface on a Discourse forum is currently much richer than what we could embed via Javascript.

+1, comments are worth it

But:
- but I agree with clime that it's pitty we can not comment directly on our page.
(looks like obsoleted tool compared to disqus).
- not being able to subscribe myself automatically to praiskup/* projects can be a good reason to migrate elsewhere in future...
- which brings me to a fact that we should take the "migration out" a bit seriously and be prepared to not get locked-in (it would be frustrating especially for users to loose the comments)

I think this is not the right place (nor project) to push for these features. Fedora projects have chosen for some reason Discourse. If there are some missing features (and I would love to see all those mentioned here) we should push for them on fedora-devel ML or on the equivalent level on Fedora Project. But not here.

If it is not possible to comment in embedded mode, then we should consider implementing our own solution. It is just one table in db. Only logged-in users will be able to comment so we don't really need to take care of spam. Deletion of comments we can just do on db level. And notifications we can do by fedmsgs (or other messaging framework). This will be good for other Copr instances as well because we will be immediately able to share the solution with them. This is basically one-day implementation so I would probably prefer that in contrast to solution that doesn't exactly suit our needs and is being constrained by somebody else.

It is just one table in db.

It is not. In past, I implemented a discussion system several times. It has been always discovered by spammers (even if that required account). So it either required a lot of moderation of work or adding spam filters and moderation features. Then people ask for marks up, or HTML elements (we had this issues in Copr description as well in past). Then comes badges. Notification when someone mentions you. Mobile application. Administration interface.

These are already implemented in Discourse - and many more https://www.discourse.org/features . And it is way more than one-day implementation.

As Discourse is an open-source, anyone can implement the missing feature in a core or as a plugin https://github.com/discourse/discourse

@praiskup Discourse has a backup feature: https://meta.discourse.org/t/move-your-discourse-instance-to-a-different-server/15721 technically it is tarball with db dump. This can be used if we ever want to move to some other implementation.

It is just one table in db.

It is not. In past, I implemented a discussion system several times. It has been always discovered by spammers (even if that required account). So it either required a lot of moderation of work or adding spam filters and moderation features. Then people ask for marks up, or HTML elements (we had this issues in Copr description as well in past). Then comes badges. Notification when someone mentions you. Mobile application. Administration interface.

Well, given that we send messages on new comments, we don't need to take care of notifications and badges. There are services already hooked into fedmsg bus (FMN, Fedora badges) that do it. Does discourse send fedmgs or something similar that fedora message notifier could handle? Administration interface - we can just go with postgresql command-line. For markups, we can use exactly the same thing as we have for project description and instructions already. And mobile application...ok, but we can do something which is kind of responsive so a user can comment on a mobile phone. I wouldn't be worried about spam too much. You need to have Fedora account to comment. Nobody is spamming new projects (except dnf).

I also have experience with both: embedded solution (Vanilla Forums) and hand-made solution and I prefer the hand-made one mainly because if you need some features you can implement it yourself.

These are already implemented in Discourse - and many more https://www.discourse.org/features . And it is way more than one-day implementation.

Well, but I don't think we need those many features. We just need something simple that works and that enables user to comment directly on comment page and potentially also give some karma to the project (which is next thing I would like to implement). The basic implementation can be for sure done in one day. Let's have a coding session together to do it!

As Discourse is an open-source, anyone can implement the missing feature in a core or as a plugin https://github.com/discourse/discourse

Yup but the project can have certain "policies" and they may refuse to implement what we need (which is likely going to be the case with commenting in embed mode).

I am ok with having some Fedora discussion forums but for us, we just need to have the ability to comment on a project in Copr, which should be simple for user to do.

I am with @msuchy here. When there was only disqus, then we could object, that it is a third-party service and that people might not trust it and that it can have some restrictions, etc. Then implementing own discussion system could worth it.

However now, when there is a discussion service for the whole Fedora, we should at least try to use it. We can try to implement missing features by ourselves and possibly get them accepted under some terms. Everyone can benefit from it. If not, we can always migrate to our solution later, as @msuchy mentioned above.

@msuchy gave me a temporary admin access to the Fedora discourse instance, so I've created a small CSS style for the embedded iframe, in order to be consistent with the rest of the site.

.copr-discussion header.discourse a { 
    color: #2b64b4;
}

.copr-discussion .username a.staff {
    background-color: transparent;
}

.copr-discussion footer .button {
    background-color: transparent;
    color: #2b64b4;
}

.copr-discussion footer .logo {
    display: none;
}

Screenshots here:
1. Start discussion - https://frostyx.fedorapeople.org/pagure/discourse-start-discussion.png
2. Some comments - https://frostyx.fedorapeople.org/pagure/discourse-comments.png

Once this PR is merged, some additional template changes should be done. e.g. Some vertical space between repos and the discussion, maybe some header ...

I am with @msuchy here. When there was only disqus, then we could object, that it is a third-party service and that people might not trust it and that it can have some restrictions, etc. Then implementing own discussion system could worth it.
However now, when there is a discussion service for the whole Fedora, we should at least try to use it. We can try to implement missing features by ourselves and possibly get them accepted under some terms. Everyone can benefit from it. If not, we can always migrate to our solution later, as @msuchy mentioned above.

Ok, can you open the PR against upstream implementing the answering in embed mode and link it here? If not PR, can you open an issue to at least see if upstream is willing to implement the change?

So I went to https://copr-fe-dev.cloud.fedoraproject.org/coprs/clime/example-new/ and I waited around 15 secs so that the discourse iframe is loaded. Then finally I clicked 'Start discussion' and it redirected me to https://discussion.fedoraproject.org/t/clime-example-new/267, where msuchy is seemingly owner of clime/example-new project. I then went to settings and changed project description but the first post in discourse with the project description stayed the same. So the integration doesn't seem to be perfect there.

  1. Start discussion - https://frostyx.fedorapeople.org/pagure/discourse-start-discussion.png
  2. Some comments - https://frostyx.fedorapeople.org/pagure/discourse-comments.png

Are those avatars there avatars from libravatar as other Fedora services use?

Is this going to be connected to Fedora badges because at https://www.discourse.org/features, it mentions its own badge system.

Will it notify users through FMN?

Also note that for spam protection we have Basset system in Fedora, which uses machine learning to catch the spammers so we don't need that functionality of discourse as well.

To summarize, I don't see this as a good solution for us. It's very nice tool as a centralized discussion forum but it's not very suitable to be a platform to host comments from other sites that already have other integrations they want to leverage.

So I think we could just sit down for a while and code something that will actually serve us well.

As per internal discussion, I am closing this PR.

Pull-Request has been closed by msuchy

7 months ago

Can you sum-up the reasons to close this?

Well, at least from what I remember - we were all OK to merge this except for
@clime. It is ridiculous to let any associate to veto anything. I thought we've
setup fair voting system.

Even if this was never used on Fedora production instance, it is still worth
having that support in source code. Since there's the "backup tarball" feature -
we are not facing a lock-in situation, so there's absolutely no reason to
not give it a try...