Etherpads such as those provided by the Gnome project are temporary collaborative working areas, and as such they are not backed up which makes them unsuitable for long term content storage. They are also being reused, recreated and multiplied leading to content spread across multiple, untracked Etherpads.
This is a summary of discussion I had with @jflory7:
Content cannot be exported from a working etherpad, other than using the ubiquitous copy/paste. In order to export the content into a permanent, backed up environment (such as a wiki or a version control system) the content in etherpad must be formatted according to the target markup language or a format supported by existing converters such as Pandoc.
We need to either 1) find a way to export the content from Etherpads to a backed up medium that allows future imports into the same etherpad (if still available) or a new one or 2) find a different solution that provides the same collaborative functionality.
As alluded above we can all agree to editing the etherpad content in an easy to read, plain text markup language such as reST or Markdown and then use Pandoc to export into a Mediawiki page. The reverse process also works thanks to Pandoc.
We can also store the formatted content as is in Pagure and make use of its revision control.
Alternatively we may want to look into other solutions that provide the same functionality as Etherpad but can be hosted within the Fedora Infra.
Discussed in 2016-09-13 meeting.
We had time to discuss this during the meeting, and I think Options 1 and 2 are the most feasible. In general, the flow for both options would be like this.
Personally, I am favorable towards using a Pagure-oriented workflow, but I also really like git. I want to know how others feel about this or if git is an area of experience that people would be comfortable with using to access notes and logs from things like hack sessions or other data stored in our Etherpads.
I encourage you to consider two things:
The wiki is ideally used for "whiteboard" style information of a short life time. We aren't doing that today, but we should encourage that.
If you use AsciiDoc format you can consider publishing the output on a more durable site in the future with the new documentation toolchain.
In my experience, etherpads are often thinking spaces and what is there should be deleted quickly. This prompts you to get it into the blog, doc, or other actual location quickly.
Given that we haven't had a hack session in a fair amount of time, that was a lot of the original motivation behind this ticket. I did some ticket triaging with @bee2502 and we agreed that if we resume the hack sessions or other collaborative sessions outside of meetings, deliberate focus would be needed to convey the info about whatever we accomplish off the Etherpad. This would either be ticket comments or blog posts, or some other form of external reporting.
Since we aren't actively using Etherpads for storing current information like we were before, I'm going to close this ticket. We can always revisit it later if it crops up again.
Metadata Update from @jflory7:
- Issue close_status updated to: Not possible
- Issue set to the milestone: Fedora 26 (was: ASAP)
- Issue status updated to: Closed (was: Open)
to comment on this ticket.