Public Lab Research note

  • 1

Wiki discussion

by Ashan |

About me

Name: K.A.A Priyadarshana


Gitter nick: aspriya

LinkedIn profile:

Affiliation: Bsc(Hons) in Information Technology, Faculty of Information Technology, University of Moratuwa.

Location: Colombo, Sri Lanka (GMT +5:30)

Phone: +94711005491

Project description

Abstract/summary (<20 words):

Making wiki pages more interactive and discussion-oriented by adding features like commenting, suggesting and tagging special parts of wiki.


Wiki pages are web pages that anyone can create or edit. We use them to collect information, documentation, and instructions on projects. At present we can create wikis, edit them and associate tags with them. But we can not add comments to this, can not make suggestions, can not tag a user for a special part in the wiki. We can make wikis more alive by implementing these features. And as shown in the diagram, implementing these as in Google docs would be more attractive. For this I will use the publiclab/inline-markdown-editor. After implementing these features, a brief look of way of posting a comment is show below.image description


image description


Additional notes or documents regarding wikis would be great. And I need guidance from Public Lab director board and from my mentor.


Yes I have forked the publiclab/plots2 repository and I have a running version in my local. And I pulled all the updates with remote repository.

Forked repository


Before I attend to university I did course on higher diploma in IT. In there I learned Java, C#, PHP and other most Basic Web Technologies. I learnt fundamental web building blocks from PHP and from codeigniter framework. At University, I moved to ruby and Rails as a web development framework. I have experience in technologies such as Ruby, Java, JavaScript, HTML, CSS, GIT and frameworks/libraries such as Java SDK, Android SDK, CodeIgniter,, Ruby on Rails, etc. I also managed to work part time at a company called Vesess which is specialized in web application development, during the 2nd year of my undergraduate course. I mostly worked with technologies like Ruby, RoR, MySQL, GIT, JavaScript etc. In this time period I developed ApistaCRM by using ruby on rails And now I am an Intern at Vesess and contributing to project Hiveage by improving its test cases.

Yes I went through the contributor guidelines and I have good knowledge about Git and I am very much familiar with both GitHub and GitLab. And yes, I have almost contributed to Public Lab


Me as a undergraduate student, teamwork is not a strange thing. In the university for all the academic projects we work as a team. In first year we developed a tv-remote and computer controllable wall clock with another five students. And in second year we developed a mobile app which dispalys web sites attractively, human friendly and which removes advertisements.Both of these projects were one year long and were 5 member groups. So I know that there are barriers, failures and conflicts when working with a team, and also with my experience I know how to manage difficulties and how to communicate with team mates positively.


As a deep nature lover and an observer, Public Lab always interests me. I always admire the work you guys do. And I started my open source path by this. The first feeling of getting a PR accepted was gained by Public Lab. So Yes, For sure Public Lab always interests me.

Ongoing involvement:

These are my previous contribution to the project


Yes I Understood that Importance of this project and I can spend required time period to complete particular task without being time oriented. and since my mentors and me are in completely different time zones I can keep my communication with my mentor organization without any interruptions and delays.

software gsoc gsoc-2017 soc soc-2017 soc-2017-proposals



This is great to hear, @Ashan -- I've been thinking about how we could use inline tags to make this possible, but it's a challenge. Some things to think about:

  1. if a proposed edit is stored in the text, and applies to a section of text, like the bright [suggest:1234]**eyed fox was**[/suggest] looking for food, then what happens if the text is changes a) inside the tags, b) outside and including the tags, or c) partly outside and partly inside -- like if someone changes bright eyed to dim-witted?
  2. if a comment is made inline (if we allow this), and not on its own paragraph, if the text around it is deleted or changed, does the comment disappear? Or do we try to extract the comment and move it to the end of the line, or something complicated?

There are a lot of places things can go wrong, basically. And if we don't store comments inline in the text, then how do we know where to display them? (This is why I'm suggesting inline comment storage, actually.)

An inline comment might be like:

This person [comment:1234] went to the store.

while one on its own line might be like:

This person went to the store.


Then they ate food.

Sorry for my crude examples, but I hope this helps get you thinking about the complexity of this! I /also/ think that we should consider how comments appear while editing a section -- for example with the inline editor:

This last editor may also be where we prompt people to actually create comments -- next to the pencil button in the example, there might be a comment button.

This is a lot of info -- what do you think?

Wow, thanks for the feedback. hmm, as you have mentioned for commenting, a small comment button next to pencil button might do the job.

Yes, Due to the mentioned problems inline comment storage seems to be good. I am still thinking and researching about the issues with suggestions as you have mentioned. For a instance we could give notifications if a user is editing texts containing suggestions. But that may not be 100% solution. Have to think and research more on this.

Thanks again for these info. I forked and learning about the inline-markdown-editor. It would be great if you can share some links or notes to understand publiclab/inline-markdown-editor

Hi, Ashan - basically with inline-markdown-editor, the idea was to find a very clean abstraction, a way that the code could run with minimal context and complexity, not only on our own platform but potentially on other peoples' markdown content as well. So after thinking a long time about it, we took the model that it can be run on any markdown string, to both display (and parse) the markdown as HTML, but also insert editor forms after each section. Then each editor form would be able to submit a before and after request for replacing just that section of content. This isn't quite as flexible as Google Docs, but it's a clean API that can be tested and built on.

So I think commenting and suggesting could follow similar paths, whether or not they're developed as extensions of the inline-markdown-editor -- the key is if their behavior is easily testable, and is separable from the rest of the code. See how inline-markdown-editor has very clear and minimal points of interface -- the incoming markdown, and the "replacement" API call to a url like /wiki/replace?before=aaa&after=bbb?

That makes our code more maintainable, easier to read and understand, and more re-usable (so perhaps other projects would start to use it and help maintain it).

For comments, for example, when we render the wiki page in plots2, we'd go through the raw markdown the way we do with the inline tags, and find/replace those codes with a more fully-fledged form. But we could also try to do this in JavaScript, in theory, like we do with the inline-markdown-editor. What are the pros and cons?


Thanks Warren. These past few days I was exploring the inline-markdown-editor. Its approach is clean and understandable. So yes I think implementing the wiki's commenting and suggesting features like that is good. As now I'm confident with current implementation codes of wiki and with inline-markdown-editor codes, in coming days I'm willing to work on some previous issues regarding wiki. That should help me understand more and contribute.

As for pros and cons you asked, I see much of pros. Because implementing these features as inline-markdown-editor is good for future use. Because we have a separate module in case of any new comer to understand how it is implemented.

Thank you very much again

You must be logged in to comment.