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

_______________________________________________
gimp-web-list mailing list
gimp-web-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-web-list

Reply via email to