[Owfs-developers] New site

[Johan S. <jo...@st...>]

On 07/09/16 10:48, Jan Kandziora wrote:
> Am 07.09.2016 um 07:15 schrieb Johan Ström:
>> How did it go with the earlier discussed new homepage/wiki where we can
>> document these things?.. :) Seems every other day these questions pop up
>> on the list.
>>
> I think the most important improvement in documentation would be if we
> have it editable by more than one or two persons. That's why I suggested
> to start a wiki for it. To keep it simple for people to join the
> documentation team.
>
> To setup a new website in place of the old one, we have to contact Mike
> Kalist and Paul Alfille. They should give the okay first to use the
> information from the current website as the base.

Well, Paul *did* reply last time this was up, asking how he could help 
in transition (https://sourceforge.net/p/owfs/mailman/message/35247513/)
So I guess we should figure out what we (the active community) think the 
best solution would be, and
then work towards that.

First of all, today we have
* www.owfs.org (where is that hosted, and where is the source?)
* https://sourceforge.net/projects/owfs/ with GIT, basic descriptions, 
tickets, releases & mailinglist.

There have been some suggestions for replacing the site so far, I'll try 
to list some pros and cons, and personal thoughts.

# Migrate all info to a Wiki
MediaWiki was brought up as an example, however requires 
hosting/security etc. The same applies for most other dynamic-style wikis.
Sourceforge has some kind of wiki functionality as well (actually, we 
seem to have it.. https://sourceforge.net/p/owfs/wiki/Home/). Downside 
with SF wiki is that it is embedded into SF site.

Pros:
  - multiple contributors easy, no need to learn git/coding to contribute
  - often WYSIWYG editor.
Possible cons:
  - we might need to handle another access setup, possibly separated 
from GIT access. Could however be a good thing, to not permit git access 
but permit docs contribution.
  - hosting? Good and flexible system?

# Setup static docs
Statically generate docs (somewhere) and push them to static hosting. 
For examples, generate from some source, using Sphix, jekyll or similar.
Hosting can be done for example on pages.github.com, readthedocs.org. Or 
hosted third party somewhere.

Pro:
- would be able to properly version it in git
- Could integrate with automatic build on push, using pull requests for 
contribution etc.
- static is simple
Cons:
- Depending on how it's implemented, it could be trickier to contribute. 
But most contributors are probably somewhat tech-savvy anyway..

---

I'm going to lift a followup question: should we stay on sourceforge? 
Even if Github may be hyped and nowadays used by every granny and her 
cat, it *is* a lot better than Sourceforge when it comes to git.. and 
everything around it..
We would certainly not be the first project to leave SF.. They may not 
yet have covertly bundled installers and what not with owfs, but who 
knows.. 
(http://www.infoworld.com/article/2931753/open-source-software/sourceforge-the-end-cant-come-too-soon.html).

I haven't looked at github pages much more than during writing message, 
but something like this is tempting:
* Move project to github: git hosting, issue handling, pull requests.
* Setup new github pages, automatically built by pushing to either main 
repo or a separate site repo. If we juse sphinx,  jekyll, or plain 
markdown, or something else, I don't know.
* Handle contributions to docs and source the same way: pull requests

Github could thus handle: GIT, basic descriptions, issues, pull 
requests, pages (site), releases.
However, not mailinglist. We could keep that at sourceforge though.

(as it happens, I just created https://github.com/owfs. If we're not 
going to use it, then at least so no-one else can steal it.. :))

> If we had to rewrite from scratch, that would be an awful lot of work.
That it would indeed.. But at the same time, we would need to go through 
everything and clean out a lot of old/bad examples anyway. I'd say, 
unless we're to keep the old site totally, we need to go through all 
pages and move/filter the content.


Johan