Re: [Gimp-web] Proposal: gimp-web-revamp

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 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
( 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

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


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]