Thank you all for your feedback! Regarding your questions: 1. Can we extrapolate (anec-data is fine here I would think), what the top three main purposes a person might land on the GIMP page for? For instance, if I were to guess it would probably be download, tutorials, help. Whatever the consensus may be, I would focus the design on answering those top three reasons as prominently (and clearly) as possible. I feel this should be the first question we should be asking ourselves (and answering). I agree. If we look at Google Trends and the Google Analytics that Alexandre mentioned, we can get an idea that users look for downloads in the first place and we should aim to have a "Landing page" for GIMP. If we can get more info from other "analytics" sources, that will help us even more.
2. The current site is already a static generated site mostly (entirely? still not sure how the news articles are created). I don't mind moving to other systems (I am building http://pixls.us in a similar vein using node.js and metalsmith personally), but is it an option that makes the most sense? I'm just asking - my opinion is that it does make sense, and that using markdown/YAML-front-matter is fine. At the moment, contributing to the site is a rather messy affair for anyone not comfortable with the toolchain and environment (but once they are, it's a very simple effort and not significantly harder than using an intermediate markup language).
Yes. I actually cloned the current repository (https://git.gnome.org/browse/gimp-web) and took a look at it. As far as I understand the content on the website is done with HTRW files, which are HTML files with includes inside of them that are processed by Apache (kind of like a templating system). I think the "problem" in there is that you have to mix content with HTML syntax and includes. Maybe for people working on the main website and news that could be fine, but non-programming people could think of that as a messy process (when writing tuts, or docs). That being said, I think a good way of attracting contributors is to get things simple, and ask for people to just write content (markdown). What I'm suggesting here is an improvement rather than a total revamp, as the current method of contributing to the website is similar.
In fact, a sub-question to this point would be: is there a method we can achieve our goals while including a simple means for others to contribute? I'm a fan of lowering the bar for contributing (technically), to help increase possible throughput of good material.
I agree. That should be the final purpose of this. First, we simplify the process by letting users focus only on content, and further work could involve developing (or extending) apps so people can't forget about explicitly cloning and pushing to git repositories and at the same time having a secure and reliable platform (git over SSH or HTTPS will give us secure channels of communication, and git itself brings integrity and version control of the content).
3. Should this discussion also include possible migration and management questions surrounding the registry? It's a problem that will need to be addressed at some point, as the current infrastructure is a bit creaky.
Keeping thins separated should help in case of migration, as the content would be in standard format (markdown) and the design would just be HTML files. As for the website content generator, we could even change the application (jekyll, pelican, etc) without problems. Regarding management, at first it indeed would be a manual process (asking for pub keys) but as you said, we should address the improvement of such a task in the near future. I imagine something like Github, when you go to your account settings and they tell you how to generate and upload your SSH key.
Because this works, and doesn't need any complex UI and functionality in the website which will only re-implement features that are available in text editors, IDEs and version control systems.
Exactly. In fact, my proposal was based on the current workflow of the GIMP website. I saw that you handle a Git repository, with scripts to generate the static content, and I tried to make a proposal as close to the current workflow in order to have something that could actually be implemented. Perhaps the title of the proposal is kind of misleading (revamp).
BTW, I'm not sure if adding gitolite is really necessary - or even possible; we are using the GNOME Git repository, and they are in charge of access control there.
Well, I thought you had your server in your own. In that case, we could think of keeping the current gimp-web repository in the GNOME server, but adding submodules from Github. That means we could create (free) repositories like gimp-tuts, gimp-news, gimp-docs, etc. on Github and let all of the authorization and user management be handled by them. Thus, the workflow for news, tuts, docs, is open and public in the github servers and the critical "merging" of all of that will be on GNOME server. Using github repos could also help to attract collaborators, as they are in a continuous work of developing friendly tools for collaboration (like the text editor Atom).
If we don't have the manpower to provide QA and security check for addons, we can't take the registry over. Again, just my opinion.
We could let Github take care of registry and authorization :)
The rest of the proposal look very good to me
Thanks! I'm very motivated with this idea so I appreciate all of the feedback. --
Attachment:
signature.asc
Description: OpenPGP digital signature