Move ontoportal.org website content to documentation web site (unique point of entry)

[jonquet]

We are currently refactoring the OntoPortal documentation.
See : #1

I am concerned about having 2 websites each of them running on different technologies and not edited/maintained with the same procedures:

• https://ontoportal.org/
• https://ontoportal.github.io/administration/

I am suggesting to move the current https://ontoportal.org/ web site content (current and past posts) to the same architecture based on github.io. With the news features described here : ontoportal/documentation#4 , we can create a section "OntoPortal Alliance" that will contain the detail about the Alliance while the rest of the web site will contain the details about OntoPortal as a product. With a unique website, which content is hosted on GitHub (https://github.com/ontoportal/administration => noted than name will be moved to "documentation") we will setup only one procedures (based on forks and PRs) to edit the website.

[syphax-bouazzouni]

I agree on moving the current https://ontoportal.org/ web site content (current and past posts) to the same architecture based on github.io, but not at the same repository as the documentation.

But I would suggest to have three separated repositories: (but with the same technology behind)

• https://github.com/ontoportal/documentation => https://ontoportal.github.io/documentation , for all our documentation (development, administration and users. With the home page as a link between them)

• https://github.com/ontoportal/ontoportal_site => https://ontoportal.github.io, for the products description (the https://www.bioontology.org/ site but for ontoportal) + https://ontoportal.org/ (the alliance description and blog posts) + a link to our documentation and github. (we can choose a template here https://jekyllthemes.io/)

• Optionally (@graybeal proposition) https://github.com/ontoportal/user_documentation => https://ontoportal.github.io/documentation/users for user guides (I don't totally agree with this, for example we can see that the Github documentation is centralized all in one place and they have a lot more topics)

Why ? Because it will complexify to much the code of the documentation and "users will get terribly confused if confronted with all of that in one package" (@graybeal words )

[graybeal]

First, it’s usually a good practice on forums like this to have discussion before calling a vote. I request that be our future practice.

I support the admin, dev, and docs sites in GitHub in similar ways, along the lines Syphax has suggested. Not sure if best as one repo or 3 but try it whichever way and see.

I am not clear if ontoportal.org would be abandoned, redirected, or what. But having IRI that as a home site is pretty valuable. If we ever have web authors to support the home site, I think they will expect to use a web authoring framework, not be limited to markdown and GitHub file management.

I could be outdated about the web authors but I think not. Still, as long as the IRI is the same, if you have folks ready to start maintaining the public site via markdown, go for it.

[syphax-bouazzouni]

• Ontoportal domain: "ontoportal.org domain name" would absolutely not be abandoned, GitHub pages give us the possibility to use a custom domain name (if you own that domain)
• Web authoring tools (no code tools) (like WordPress): I'm not closed on that, and in fact, we (I) would be happy to hear your experience feedback of the two years of using WordPress for https://ontoportal.org/ and https://www.bioontology.org/.

[graybeal]

Regarding web authoring tools, having done community sites in plone(!), Drupal (twice), a brutal Adobe product), various wikis, Confluence, pure HTML, WordPress, GitHub Pages, GitHub Sites, and ReadTheDocs, I conclude that the last three are quite good for information and sharing, but they can’t do emotions and marketing. I’ve spent a lot of time trying to work around the markdown limitations and I think it’s not possible.

I think our internal “community of interest” is all developers so GitHub is good so long as Microsoft doesn’t mess it up. But to communicate to the wider community the Alliance will get best results from a professional web design product. Unless there really are zero people or funds to use it.

[jonquet]

To me we need to select/setup the simplest infrastructure and avoid having accounts in several places (on GDrive, on Slack, on mailing list, on GitHub and on WordPress). So I suggest to simplify our ecosystem by removing Wordpress and moving everything to the same collaborative-driven approach.
Personnaly, I do believe that editing WordProess will be nicer and quicker... but that not the choice I am advocating in the Alliance (considering the current status of course) ; the web site is here four 4 years and no one has never touch at it except one editor. That's what we need to change.
Once we will have procedures to PRs and accept code for the main code repo, we would follow exactly the same one for the web site.
For instance, a member (or someone considering his/her group as a member) can fork the web site then PRs a new version of a new page on the web site where his/her group will be listed.

[graybeal]

Well, your arguments are practical for our state of play. I will change my vote.

[arsarkar]

I abstain, i.e. Whatever is decided is fine with me.

[xeniacs]

I agree with Clement's proposal for a single website.

The structure and number of the repositories may be as Syphax proposes, as long as the public entry point for product description, alliance info/newsblog and documentation remains a single one.

With regard to the User Guide, I believe users will be happy as long as a Users' section is clearly indicated in the documentation. So, the page can have a jekyll theme that allows for several sections/subjects to be reached from the front page, but a user should be able to distinguish immediately the section most probably holding the answer to his usage question.

[jonquet]

I am fine with one signe web endoint at ontoportal.org and fine to if it points to 2 (would not go over 3) different web-site repos in the back.

[graybeal]

Heh. Not obvious how to change my vote. We'll get over it. :-)

[syphax-bouazzouni]

I close this conversation as it's resolved here #21