As you've probably noticed, we're ramping up to get a new site framework launched as soon as possible, and start the ongoing process of improving & refining its content. Thanks to everyone who's provided some ideas and inspiration in our discussion topic from last week -- it's not too late to add ideas if you have more:
Moving forward, I wanted to get feedback from all of you on the website team (as well as the ODK PMC & the "general public" too) about some "requirements" for what the new release of the web site should accomplish/include. These are based on some earlier discussions, but it's not too late to change or improve them.
7 Key Requirements
The new site should have an open team of self-identified volunteers -- @website-wg -- to help support it over time.
The content of the new site should be up-to-date and reflect the current state of all of our community's major software development work. (There may be some "experiments" & smaller projects not mentioned.) This includes pointers to end-user & developer documentation for the ODK 1 & 2 families. Some content may live on the forum or other documentation sites. The "download" section should also be improved.
The site should "go live" as soon as possible, with a goal of launching the "first new release" at the end of January.
The technology platform should allow anyone to recommend content changes, and ensure those content changes have some type of peer review process before going live.
There should be a system to allow different individuals permission to edit different parts of the web site. (e.g., Not everyone should be allowed to edit the home page, but folks should be allowed to make changes to their own specific project content.)
Where possible, URL redirects should be used to avoid broken links from old versions of the web site.
The site should allow easy updates & "growing room" for a new ODK logo, new project names, and other organizational & strategic changes from the PMC (and any successors) as well as software projects teams such as the TSC's. It should not be stressful or difficult to deploy these content changes as ODK projects grow.
So, what do you think? Please vote here:
These look good to me!
No strong opinion.
I've got a suggestion or new idea to discuss. (Please comment below.)
By the way, I understand that the PMC is going to meet on Tuesday. It would be fantastic if they could (individually or collectively) review these items too and provide feedback in addition to everyone else.
Overall, these look good to me, but I would drop #5 because it adds constraints that aren't needed. If you have #4, then instead of requiring explicit permissions, we just need to make sure that changes are reviewed.
Thanks @yanokwa for pointing out that overlap. I do think 4 & 5 are tightly related. Personally, I'd think that as long as we make sure that the people "reviewing" the changes to the web site are trusted with all areas of the web site, then that review process probably accomplishes the idea about "permissions".
Does anyone else have a strong feeling about that topic? (Or others?)
Surprised that @yanokwa is now suggesting dropping 5 since he was the one that wanted to make sure a person working on ODK 2 could not change webpage content for ODK 1.
Personally I think (and hope) that would still be covered in a solid "code (content?) review" process. Or at least whatever the person was suggesting is both (a) factually correct, and (b) run past whatever project team to make sure the content was OK to announce/change/edit/whatever.
Of course this is still hypothetical and we'd need to make sure the process had a point to validate these things!
@W_Brunette My goal is to ensure that the folks who are responsible for the specific tools have a big say over the content covering those tools. I think a solid review process driven by maintainers (same as we have in the code) is sufficient.
I agree that 4 and 5 can be combined into one point about review process. What I find important is easy access to edit history with attribution. As long as anyone can audit what changes were made when and by whom then it's clear when the process is working well and when it isn't (see Wikipedia, e.g.).
Regarding point 3, I agree that creating a website that better captures the current state of the project is important. It's wonderful to see structure and process put in place to make progress. But to me it's much more important to define what "good" is and get to something "good" than to just move quickly! This process was only started a few weeks ago and although I agree speed is important I'm not in favor of setting an aggressive timeline if that means sacrificing quality.
Thanks everyone for your feedback! We can of course always come back and re-visit these as the site evolves, but I think we've got pretty clear alignment for the next phase. Stay tuned for more opportunities to participate!
