Content
1. Introduction
This will be my only “big picture” planning document for software development and maintenance in Edgeryders for the next three years (2019-2021). Basically all software we’ll make will be used in at least two projects (which is good), so it makes little sense to have separate planning documents for each. It’s all in here: for POPREBEL, NGI Forward, Trust in Play, Tiramisu, Biofabforum (relaunch as federated platform), Blivande and any other Discourse based platform we’ll create in that period.
Downstream from this document, there will be software design documents for specific software tasks in Dynalist and Github issues. The associated Dynalist tasks also contain the intermediate, internal deadlines / milestones, if any.
For the list of requirements implemented by this plan, see “Tech dev specifications for POPREBEL and NGI Forward”.
2. Work plan
Below is a list of the IT team’s work units (major features and software modifications) that we’ll do in 2019-2021 for Edgeryders’ client projects. They are mostly structured as one work unit per software tool.
The entry for each work unit contains a short discussion of the requirements and planned software architecture and software design to implement it. Often, this summarizes discussions further down in this topic.
2.1. Discourse
-
Login integration for federated platforms. Our new solution for providing whitelabel Discourse platforms will look very similar to the Stack Exchange network of sites: one installation, different databases, but synced user accounts and login sharing between them. All of this is already possible using the Discourse multisite feature and existing SSO provider / client plugins, so we’ll “only” have to deploy all this properly. There will be no content syncing / embedding between sites, such as via special categories on the frontpage etc., as that creates problems with syncing when running out of category levels. -
Site switch menu. Sites in our future network of federated Discourse sites will be coupled via a site-switching menu in the top right. This may be placed to the side of the hamburger and user menu, or in a menu bar above that, whatever is better for UX and from a tech perspective. It will simply list the federated sites.
-
Discourse-to-Discourse migration script. To archive and safeguard the content of federated Discourse platforms after their decommissioning, we’d have a script that imports all that content into edgeryders.eu. Due to the single-sign-on feature, all users of the original platform will be able to log in and contribute under their original usernames, still. The import script would also have to update links in post content, and forward links from old URLs to new ones (such as whitelabel.net/t/123 → edgeryders.eu/t/19345). The latter would be managed via automated creation of Discourse permalinks, as we did successfully for our Drupal-to-Discourse migration. With such a script, our whitelabel offering would be complete, covering the full life-cycle of a platform.
-
Improved signup and login processes. Due to the “Edgeryders Communities” mechanism, the signup and login processes are not as smooth as they could be. We’ll improve that as follows:
-
Implement that users are logged in automatically after successful signup.
-
Implement a signup form right on each Communities site that uses the new API developed for “Posting to Discourse from an external site” (see below). That signup form would first issue an API request to communities.edgeryders.eu to create an account with the supplied information, and then issue a regular login API request to the current Communities site.
-
-
Table of Contents plugin. A small plugin that can generate a table of contents (in the format following our conventions) when pressing a button in the post editor. Not essential, but we need it quite a bit and it would save us time when writing documentation, and would enable users to contribute more structured, better navigable content. Seems a good thing to have for NGI Forward, as discussions will be quite technical at times.
-
Cross-platform notifications in the site-switch menu. (optional) Implementing this depends on having another paying client for a federated Discourse platform after TeaM2021. Technically, it will be an improved version of the existing site-switch menu (see above), now also showing the notifications from the federated sites. A number bubble for the menu entry of each site would sum up the normal (blue) and message (green) notifications that the user has on that site, and perhaps there would be another number bubble (or a white square this this time?) with the number the user would see in the “Unread” section of that platform. The dropdown menu label itself – perhaps “Communities” – would sum up the notifications on the menu entries it contains. The current platform would be listed in the menu but without notifications, to not confuse people.
Later, in an improved version, we could allow the menu entries to fold out, revealing a list of the actual notifications as shown on the federated Discourse sites, with direct links to posts and messages there. That may or may not be good UX, though. Probably it would be good because it’s also done this way on Stack Exchange.
Finally, there should be a setting in the user profile so the user can choose if links from these menus to federated sites are opened in the same or a new tab.
-
Content cross-promotion plugin for federated platforms. (optional) A Discourse plugin that cross-promotes posts between multiple federated Discourse sites. Comparable in function to the “Hot Network Questions” feature in the Stack Exchange network sites sidebar. Implementation proposals:
- Create a new entry “Discover” that is displayed in the “Categories | Unread | New | Latest | Bookmarks” menu and shows interesting content from across the Edgeryders Communities sites.
- Show topic proposals from across the Edgeryders Communities sites at the bottom of the page, below a topic.
-
Federated Discourse platform software to download and install. (optional) Since this is a “nice” software product that others may want to re-use and even contribute to, we will invest some effort into proper packaging. Ideally as a Discourse plugin that would simply have to be installed in all federated sites to provide the notification integration (while login integration is provided by the existing SSO plugins).
-
Improved cross-platform user interaction. (later) Currently, @mentions work only between users of the same Edgeryders Communities platform, sometimes causing issues for community builders of confusion to users. We can improve on that in several ways, and we still have to decide which ones we want. Examples:- True cross-platform @mentions. They are not easy to implement though. And the implementation should keep it clear which users are part of the own platform and which are part of external platforms. For example, by mentioning the platform URL(s) behind username proposals that are not part of the current platform.
- Enabling the user directory and messaging on communities.edgeryders.eu, at least for staff members. That’s a simple fix and could already help/
- Noting on user profiles on which Edgeryders Communities platforms a user has an active account. This information would be collected and distributed by a script looking into the databases of all the Discourse platforms.
-
System for automated translation of post content. (discarded) This would provide buttons below each post that allow to view a machine translation of that post into the user’s own language. Machine translations would be cached to make the system faster and to lower the cost of API usage.However, in the team call 2019-02-04 it was decided that we do not want this feature for the POPREBEL or NGI Forward platforms. For POPREBEL it is not needed as the plan is to provide one sub-forum per language and focus community management on one community per language. For NGI Forward, the concern is rather to better not use Google, Microsoft etc. technology, which includes to not use their machine translation technology.
Budget: [TODO]
2.2. Project websites
Project websites are small websites that provide additional interfaces to projects and their content. More beautiful but less complete than in Discourse. We called them by other names before: minisites, static websites, façade websites, presentation websites, frontsites, … .
Discourse project website toolkit
A re-usable framework for a single-page or few-page website that “looks pretty”, presents a project that is active on a Discourse platform and displays static textual content, featured content and information / statistics about the Discourse content, all taken from that Discourse platform, and, where relevant, linking to it.
Note that taking the site’s static content from Discourse means that Discourse users with the necessary permissions can edit the façade website right away, without needing another account etc… For an example of this mechanism, see the topic about the Blivande website. Ideally, that static content would be accessed from an access-protected Discourse category using a suitable Discourse API key. To know which content is edited in which Discourse topic, there should be a “secret” mechanism that will display overlay links for editable areas after appending a certain “secret” GET parameter to the site.
For reasons of security and server load, no server-side scripting should be involved in page rendering. A client-side web application could query the Discourse API using JavaScript, but that puts unnecessary load on Discourse. So the best alternative seems to be to use a static page generator and let that run regularly (1-2 times per hour?) on the server to re-generate the static façade websites. If that page generator would use Handlebars as its templating engine (the same used inside Discourse) it would be perfect to build a small companion software for Discourse that can be released as an open source application.
An implementation of this using Ruby and Middleman is now provided as websites-from-discourse. A second, parallel system with a JavaScript single-page-application architecture is also under development by @owen but not yet published as a framework (however already as sites using this approach).
Posting to Discourse from an external site
The requirements are discussed in detail in this topic. The API for this is now implemented and documented in our API manual.
Budget: 1500 EUR
2.3. Open Ethnographer
-
Code internationalization. Called “multilingual coding”, but that’s rather a misnomer; the idea is not to allow coding foreign language text, which is already possible, but to allow ethnographers to translate codes, esp. for re-using those of other researchers with names in ones own language.
There were two proposals to implement this, and @matthias decided that the implementation should be to translate code names. Rather than creating new codes in a different language and using them as child code of some parent code (as @alberto proposes). Because the latter is already possible with ones own codes anyway, and we’d like to avoid implementing multiple parallel hierarchies for codes as that is a messy data structure.
-
Multimedia coding. Relates to image, video and audio annotations of content embedded in Discourse posts. Requirements to be decided in detail together with @amelia and @mette. The current, rough implementation proposal by @matthias:
For images, we would integrate an existing image annotation solution that uses Annotator.js 1.2. Ethnographers would be able to select any rectangular area of an image with the mouse, add a code to it, and repeat as often as needed for an image.
For video and audio, we would keep the usual Discourse system in place where the actual data is stored on an external platform and embedded in Discourse via Onebox embeds. Currently, people can use YouTube or Vimeo for video and Soundcloud for audio. This is how posting video and audio content works on a Discourse platform, and changing that user experience is not a good idea. (Also, while there is the discourse-brightcove plugin which can directly upload from Discourse to Brightcove, the pricing of Brightcover is just completely over the top for the low-throughput needs we have here.)
For annotating videos, we will use the Open Video Annotation software, which is based on Annotator.js 1.2 just as Open Ethnographer right now. Its licence is GPL, just as that of Discourse and Open Ethnographer, so there are no issues with distributing both in the same repo. Annotations for videos created that way would have a start and stop time, but not additionally an associated part of the video area. This way, they work much like subtitles.
Using Open Video Annotation requires us to have the video files accessible on our server, at least in the coding view. Because for example the YouTube Terms and Conditions forbid to show their videos in third-party player software directly (see). This is somewhat enabled by Discourse already because uploading a
.mp4file will show it in a HTML5<video>element, embedding it as a video to be played with the browser’s integrated player (example). So the only thing to do is to load thevideo-jsplayer (required by Open Video Annotation) in the Open Ethnographer coding view, in such a way that it takes over rendering the<video>elements from the browser’s internal player.Now there is the problem to distinguish between videos created by the post author (that should be coded) and embedded third-party videos (that should be ignored). We don’t want irrelevant videos and sound file to eat up space on the server. Software can’t recognize which is which, so a manual action is needed. In addition, Discourse is not a video hosting platform so cannot deal with transcoding video and audio obtained from third-party sites. So the following process is proposed:
-
When ethnographic coding starts, the ethnographer or tech support create local versions of all embedded video and audio files to be coded. This would be a staff-only action by marking
.mp4and.mp3as staff-only extensions (and giving staff users higher upload file size limits). Audio files would be uploaded as.mp4videos showing a still image, thus allowing to be coded with Open Video Annotation as well. These videos are embedded in a[details="Locally hosted version"] … [/details]element below the original embedded video or audio element, by editing the post. Manual conversion and uploading also allows to minimize the file size, by choosing resolution and compression according to the type of content. If this step should be automated later, it can be performed by a bot user when triggered by a staff user performing a custom action in the admin menu of a post (“convert embedded media to local”).As an alternative that does not need manual intervention, users can upload their
.mp4video files to a file hosting service like Imgur that allows direct access to these files. Posting links to such files as Onebox links in Discourse will also embed the browser’s default video player (example) resp. in Open Ethnographer use thevideo-jsplayer as done for all<video>elements. If we want to choose this, we can give instructions to users in the upload / embed dialog of the Discourse editor, by configuring the UI strings used there. Not sure if this solution is better, as users would have to create yet another account and they would need to know a bit more about video tech for useful results. Staff users could always replace too large embedded video files with a reference to a smaller version, though.Simpler and perhaps even better, we could allow users to upload video files directly to our Discourse installation, up to maybe 300-500 MiB. There is currently no way to make this limit depend on a user’s trust level (we’d have to create a plugin for that), but in our case the probability of abuse is low enough. Again, admins could replace too-large files with smaller versions, and by enabling “clean up uploads”, the too-large versions would be automatically deleted.
-
Ethnographers will then see the locally hosted versions of audio and video files in the Open Ethnographer coding view inside the
video-jsplayer with Open Video Annotation enabled, and code them there. -
Archiving the Open Ethnographer content will simply include the local video and video files as well.
All other features like annotating audio in audio files and uploading audio directly from the Discourse editor would be something for later versions.
-
-
UI rework / improvements. Both according to input from ethnographers and according to own judgment by the developer / development team. Especially, this includes to deal with the open issues of Open Ethnographer.
Budget: [TODO]
2.4. Graphryder
Among others, this implements the “interactive dashboard” (version 1 and 2) as called for in the POPREBEL and NGI Forward tech specifications. It also includes features that let us use Graphryder as a community management tool, replacing Edgesense.
-
Installation process documentation and small fixes. Done by @hugi, the task being “setting up Graphryder for OpenVillage data, and documenting the process to be reused for further corpora”.
Budget: Initially 1600 EUR from Edgeryders Core funding. Since that did not suffice for the work, we assigned “some more”, also from Edgeryders Core funding. All of this is already paid.
-
Maintenance and repair. Both Graphryder Dashboard and Graphryder API are in dire need of major maintenance and repair work before we can reasonably proceed to add more features. The issues to work on are simply the important issues from the current lists of Graphryder Dashboard issues and Graphryder API issues.
-
Dataset switching. The ability to switch between multiple datasets ("“ethnographic corpora”) in one Graphryder Dashboard, instead of the current hack of having multiple installations of Graphryder Dashboard for that purpose. Every normal application is able to work on multiple “files”, so this is really an essential feature. This realizes the “interactive dashboard v1” deliverable. It will also allow users of the Edgeryders Communities platforms to analyze the dialogue happening in their forum.
Implementation proposal: extend the
config.jsformat so that multiple Graphryder API URLs can be configured there, each with an associated dataset name. There would be a dropdown at the top of the page by which the user can switch between datasets, triggering the functions that (re-)load data into Graphryder Dashboard. At the start of Graphryder Dashboard, no dataset would be selected, making the site load fast. With this implementation, multiple installations of Graphryder API are still necessary (one per dataset). We don’t necessarily want to fix that, as investing into Graphryder API does not seem worth it. Instead, we will extend the API specification to support multiple datasets, at the time when we re-implement it as a Discourse plugin (see below).Alternative implementation proposal: As above, just that Graphryder API would also be extended to handle multiple datasets (see this issue). Graphryder Dashboard would then be configured with only one API URL, and get the names of datasets for the dataset switcher dropdown via the Graphryder API itself.
-
Data selection (incl. by category, code, tag, time). A way to select the content (as a subset of the associated content of the “ethnographic corpus”) that Graphryder will work on. This realizes the “interactive dashboard v2” delivery.
Implementation proposal: a few form elements at the top of the main window that let the user filter the graph content by tag, category, time of posting and ethnographic codes (which themselves are selected by their hierarchy, author and perhaps code language). Then a graph will be drawn according for the filtered data rather than for all the data like now. This implementation can be done completely client-side in Graphryder Dashboard and does not need any extensions of Graphryder API. Since Graphryder Dashboard must be able to show the full dataset – the task it has right now – filtering that data will only improve its performance as less data has to be shown in the graph.
-
Improved data downloads. Better support for downloading the graph and treating it with tools outside Graphryder, esp. in Tulip for one-off analyses. To be implemented as download option for “what is visualized on the screen” in
.tlpformat or some other Tulip-compatible format. When not choosing any data filters (see above), this download would be equivalent to the full / main graph. This would also be part of the development for “interactive dashboard v2”.
-
Graphryder API as a Discourse plugin. (if in budget) A Discourse plugin that re-implements the current Graphryder API using Ruby, PostgreSQL and (if needed to replace Node4j) Redis, which is used by Discourse anyway already. It will avoid all the syncing, performance and installation issues of the current Graphryder API, which can stay as a standalone implementation for those who nee it.
This will probably not be in budget as it is a major piece of work, but in that case we’ll integrate it into a future project. If in budget, it can be implemented as part of “interactive dashboard v2” because it provides realtime data, making the application “more interactive” as it allows to interact with live data from Discourse.
-
Evaluating post relation by quotation. (if in budget) Given the way Discourse works, creating a post as a reply is not the only way to interact with other posts. Users can also quote other posts. In fact, Discourse encourages them to quote multiple others in one new post rather than posting multiple replies to different previous posts. In turn, Graphryder should be extended to also create connections between users based on “who quoted whom”.
-
Working on the data of a whole Discourse forum. (if in budget) Together with the " data selection (incl. by category, code, tag, time)" feature from above, this allows Graphryder to take over the current use cases of Edgesense (i.e., looking at a whole forum to do community management). However, given that community management focuses on the 2-3 currently active projects and is also paid by project, this is not a particularly important feature for community managers. It will help them more to have real-time data, that is, having “Graphryder API as a Discourse plugin” implemented (see above).
If Graphryder can handle the amount of data, the implementation is not difficult. It just means adding one more dataset that is not defined via a Discourse tag but as “all content of this Discourse forum”. As the amount of data will be too much to display as a graph, it would probably be “the last 5000 posts of this Discourse forum” or similar.
-
Installable packages. (if in budget) Another improvement for better installability. Undecided yet – it would help others use the software but is not essential, so we have to wait and see if we have resources left for this.
Budget: [TODO]
2.5. Dynalist integrations
-
Google calendar integration. Mostly finished, but we’re still waiting for Dynalist staff to fix one bug for us.
-
Notifications. Mostly finished, see @anu’s dynalist_companion software. But this can still be polished and improved. Our issue tracker on Github contains all relevant tasks for that.
-
Gantt chart integration. (useful but optional) Let Dynalist Companion show Gantt charts for project management and personal task management. Such charts would help greatly to keep an overview of ones personal tasks in Dynalist, which are usually scattered among multiple projects and due to this, not ordered by date either. Elements in the Gantt chart would then link back to Dynalist.
The charts would be generated live from Dynalist documents according to the node hierarchy and constraints added to nodes via some form of custom syntax – as an inspiration, see the Gantt chart syntax of mermaid.
Then, we need a library that can generate Gantt charts as HTML and not just as static images (as that would not allow folding / unfolding, links to Dynalist and other interactions). So far, we know of the following open source software components that can do this: (1) mermaid as mentioned above; (2) dhtmlxGantt, source code being here; and (3) jQueryGantt, the component used in Twproject.
-
Freemind integration. (discarded until demanded explicitly) This is an idea developed for Anique, who likes to have a more visual way interact with a list management application like Dynalist. However for now, it seems not urgent enough and we want demand for this from others before going forward with this plan.
Technically, we would let Dynalist Companion provide a remote Freemind server and a Dynalist list editing client. It would dynamically translate between the two so that in effect one can view and edit Dynalist documents live with Freemind. Edits would ideally be posted to the Dynalist server when leaving node edit mode in Freemind, if technically possible. This would minimize conflicts happening due to concurrent edits, and if this is rare enough it can be managed with by letting the last edit win (as is current practice for concurrent edits by two Dynalist users). Not sure if this whole proposal can be technically implemented as a clean solution, though.
Budget: [TODO]
2.6. Project management and reporting
-
Financial reporting utility. This is a Python based command line utility as proposed in “Financial reporting for a Horizon 2020 project”.
-
Kimai v2 extensions. (optional, long-term) This would take the Kimai v2 time-tracking software for teams and extend it with an approval process and an auditable log of changes, as discussed in the thread at “Reporting for a H2020 project”. Given our current process there is no strict need for this, but it would make our time tracking less overhead and more suitable for audits.
-
tom / tom-ui export to Kimai v2. (optional, long-term) To make time tracking even more comfortable in our company, we would extend an open source cross-platform time tracker such as tom-ui to directly exports its tracked time to Kimai v2, the platform that would be used to aggregate, store, and approve tracked time. For more details, see the discussion at “Reporting for a H2020 project”.
-
Timetracker integration with FreeAgent. (discarded) This was a speculative idea and later replaced by a tool-agnostic process instead of requiring everyone to use FreeAgent for time tracking (see: “Reporting for a H2020 project”). And for a longer-term, comfortable and technologically proper solution, it was replaced with the “Kimai v2 extensions” proposal above.
The idea here was that if users experience time entry into FreeAgent as too cumbersome, we can automate that away with a time tracker application that records worktime right into FreeAgent, either directly or synced from local storage.
From a short analysis, the most promising technical options are as follows. For OS X, there is FreeAgent Widget (open source) and Slips (commercial), both listed in the FreeAgent extensions directory. For other operating systems there is nothing yet. There are integration platforms like Zapier, but they only sync contacts and tasks and not tracked time (sources: 1, 2, 3, 4). Also, they only connect expensive commercial, web-based time tracking services to FreeAgent – which makes little sense, as FreeAgent itself comes with a (simple) web-based time tracker inside now. What we want is a desktop widget. So we’d have to extend a small open source time tracker with the desired functionality ourselves. Good candidates are porting the open source FreeAgent Widget, or perhaps watson with crick or arbtt. The latter are both cross-platform, written in Python, but unfortunately rather geeky command-line tools. So we’d also have to add a GUI widget.
Budget: [TODO]
2.7. Server admin, support system, development tools
-
Staging website. We have a Discourse staging website, but will have to complete that system with a script that can take over data from the live site and a way to have staging websites for each of the federated Discourse platforms (also, to be able to test the login integration between Discourse sites).
-
E-mail server migration. As part of the security optimization / hardening, Edgeryders’ e-mail server will be migrated to run on the same system as the Discourse platforms. The old e-mail server will be switched off.
-
Better backup system. Daily pull-based backups to two online locations with server hosting inside the European Union. Fail-safe alters in case a backup fails.
-
Server setup improvements. Some of these will have to be paid from Edgeryders money as they are “indirect costs”. The detailed list of tasks for this will be developed directly in Dynalist.
-
Support process. (perhaps) A category in Discourse will be sufficient, but we should probably make it more known and document better how to get support.
Budget: [TODO]
3. Budget plan
3.1. Total budgets
Listed by client, approximately in the order of project execution. Budget coming from project money assigned to indirect costs (which is 20% of total in H2020 projects) is listed under point “Edgeryders Core”, since we treat it as the equivalent of “project profit”, assign it to the company itself, and decide within the core team how to spend that.
-
Trust in Play: 2,800 EUR IT budget
-
Timisoara: 3,040 EUR (4,800 EUR contract value less 20% Edgeryders margin less 2 × 400 EUR for project management by Noemi and Natalia)
-
POPREBEL: 24,000 EUR (source). Was 25,200 EUR in the original project application.
(flexible use for all IT tasks in this client project, fully flexible distribution over the project runtime)
-
NGI Forward: 21,600 EUR (source). Was 25,200 EUR in the original project application.
(flexible use for all IT tasks in this client project, fully flexible distribution over the project runtime)
-
Edgeryders Core:
-
1,600 EUR and some more that is not accounted for here. All already spent, used to pay for Hugi’s work to install and document Graphryder. Included as a 1,600 EUR budget position into the sum below.
-
5,000 EUR for server maintenance and backup system. As decided by Edgeryders OÜ directors in 2019-11.
-
[unknown] EUR for tasks falling under “indirect costs”. Some of the tasks in this document may fall under “indirect costs” and cannot be reimbursed directly in the POPREBEL and NGI Forward projects. This means they have to be funded from the portion in H2020 projects allocated to indirect costs, which is always “25% of direct costs” resp. “20% of total”. This money is managed as part of the Edgeryders Core budget. [TODO: Calculate how much core budget is needed for these tasks.]
-
-
Biofabforum:2,000 - 3,000 EUR (may include non-IT tasks for improvement)(currently excluded, as the project did not move forward as of 2019-05)
-
Total: 2800 EUR + 3040 EUR + 24000 EUR + 21600 EUR + 1600 EUR + 5000 EUR =
58,040 EUR
3.2. Project budgets
Also includes the currently unspent portion of project budgets.
4. Team plan
In alphabetic order:
-
@daniel: All Ruby based programming. Means Discourse Core and Open Ethnographer.
-
@hugi: Software designer / project manager for the extensions we intend to do in Graphryder for the POPREBEL and NGI Forward projects. This is not that much worktime, but requires creative work / vision. It would include doing the software design (incl. a rough list of features), while others would do the actual programming and testing.
-
@luca_mearelli: When we need reinforcement, an additional developer for Graphryder (Python) and also, if needed, Discourse and Open Ethnographer (Ruby, JavaScript). He told us already that he’d be available.
-
@matthias: All project management of the development work. All final decisions. Server and software administration work. Python based programming for Graphryder and (partially) the financial reporting utility.
-
@owen: HTML and JavaScript web developer for the Discourse façade website toolkit.
[TODO: Add our NZ based collaborator.]
5. Time plan
-
2018-12-03: Trust in Play platform ready. It should be the first federated Discourse platform: sharing an installed codebase with edgeryders.eu and using edgeryders.eu as a SSO provider for login sharing. The site switch menu and cross-platform notification features will still be absent and follow later.
-
2019-01-10: TeaM2021 platform ready. This would have the same feature set as the Trust in Play site (federated Discourse platform with login integration) plus the site switch menu. The cross-platform notification feature will follow if and when it can be implemented in a future project of a future federated Discourse platform for another client.
-
2019-01-29: Blivande migrated to a federated Discourse platform. (Internal target date, not a strict deadline.)
-
2019-02-28: Ethical consent funnel for POPREBEL finalized. This is a modification of the ethical consent funnel on edgeryders.eu, using different questions as agreed on with an ethics advisor. The translated version might follow a bit later. (Internal target date, not a strict deadline. Details discussed here.)
-
2019-02-28: Biofabforum migrated to a federated Discourse platform. (Internal target date, not a strict deadline.)
-
2019-02-28: Software upgrade of edgeryders.eu. Necessarily done after the Biofabforum split-off as we will remove our custom code from Discourse that we used for the first iteration of the Biofabforum. (Internal target date, not a strict deadline.)
-
2019-03-01: POPREBEL platform launch. (Was 2019-02-11 before.) This will simply be a top-level category on edgeryders.eu. A federated Discourse platform would separate POPREBEL too much from the existing Edgeryders user community.
-
2019-05-01: NGI Forward platform launch. Will simply be a top-level category on edgeryders.eu, and an own domain that works as a forwarder (or site of entry, or read-only version). A federated Discourse platform would separate NGI Forward too much from the existing Edgeryders user community.
-
2019-06-01 or later: Code internationalization feature. This is not included in any deliverable for the POPREBEL or NGI Forward project, so formally there is no deadline except the end of the project.
This 2019-06-01 date would be a good one for researchers to start coding in conjunction with the multimedia coding feature, but it could easily be pushed back a few months (esp. when providing features that allow researchers to add code internationalization when the feature is ready, while they can already start coding with codes in English or in their own language right away).
-
≤2019-05-31: NGI Forward façade website launch. A pretty-looking entry website on its own domain that works as a forwarder or site of entry for the Discourse based NGI Forward communication platform.
It was agreed that this can be done after launching the Discourse platform. Recently Nadia requested that work is started on this (and it should be finished within month 5 of the project, in line with the corresponding “platform launch” milestone of the project plan):
-
≤2019-06-30: OpenEthnographer multimedia coding feature. The POPREBEL project plan requires this as Deliverable 2.1 at “month 6”, which means anytime in 2019-06. Delivery includes “code for multimedia coding deployed, committed to GitHub and documented”. See details.
UCL sent a template for this deliverable, but probably we will not have to use it as this is of type “code”. See the grant agreement for this.
-
≤2019-06-30: POPREBEL Data management plan. “A document detailing the governance of the data produced during and after the project.” For more details, see here from “Types of data to be deposited …”. The POPREBEL project plan requires this as Deliverable 2.3 at month 6, which means anytime in 2019-06. People involved: lead by Edgeryders OÜ, collaboratively by Research Director and tech team.
-
≤2019-07-17: NGI Forward Ethical & Data Management Plan. The NGI Forward project plan requires this as “Deliverable 6.5” at month 7, so ≤2019-07-31. But the consortium leader wants to see deliverables two weeks in advance. People involved: the tech team leads Edgeryders’ contribution to Nesta’s lead.
-
≤2019-11-01: Software design for the future of Graphryder. Associated task here. Essentially done now by @matthias, see the development plan for Graphryder above.
-
≤2020-01-31: Graphryder interactive dashboard feature v1. “A software application to generate and refine on the fly visualizations of semantic social networks.” POPREBEL Deliverable 2.5 (month 13), also NGI Forward Deliverable 2.3 (month 13, means same date or later).
-
≤2019-11-01: POPREBEL façade website extension. The façade website is a pretty-looking entry website on its own domain that works as a forwarder or site of entry for the Discourse based POPREBEL platform. It was agreed that this can follow at some time after the launch of the Discourse platform. Date to be decided by the POPREBEL community management / engagement team. This task is about extending it with a “post-through-to-Discourse” feature that allows signup and posting in a single, step-by-step process. This is the same software that is being used by Natalia for the Biennale project. [TODO: Update the current status.]
-
≤2021-10-31: Graphryder interactive dashboard feature v2. “A software application to generate and refine on the fly visualizations of semantic social networks.” POPREBEL Deliverable 2.8 (month 34), also NGI Forward Deliverable 2.6 (month 34, means same date or later).
-
≤2021-12-31: Open Ethnographer UX improvements. This is not included in any deliverable for the POPREBEL or NGI Forward project, so formally there is no deadline except the end of the project. As such, it is included in the work plans of both projects (NGI Forward GA: p. 99). In practice, improvements can be done incrementally as time is available and based on feedback from ethnographers, and most of that work would probably be finished in early 2020.
-
2019-01-01 to 2021-12-31: All-time tasks.- technical support and bugfixing for the end-user platforms
- technical support and bugfixing for ethnographers for using Open Ethnographer and Graphryder
- backups
- server security updates
