[Rpm-ecosystem] rpm.org redesign feedback
lkardos at redhat.com
Tue Apr 14 16:09:53 UTC 2015
----- Original Message -----
> From: "Jan Zelený" <jzeleny at redhat.com>
> To: rpm-ecosystem at lists.rpm.org
> Sent: Tuesday, April 14, 2015 4:01:57 PM
> Subject: Re: [Rpm-ecosystem] rpm.org redesign feedback
> On 10. 4. 2015 at 09:33:25, Radek Holy wrote:
> > Hi,
> > as for https://github.com/lkardos/rpm/wiki, looks good to me. The structure
> > is very clear, I'd say.
> > What I don't like is that in the end, there is almost no content. It's just
> > a list of links to other resources. It evokes a feeling that RPM does not
> > want to bother with a documentation. I personally don't trust any
> > documentation that is outside of the project's website. But I assume that
> > you are the authors of most of the linked documents so that is not your
> > case. It's just the feeling.
It's not just feeling. Documentation is mix of links to many resources,
each one describing other feature of rpm. Most of them are not written by us
and many of them are out of date and contain wrong information. It would be
nice to have one document from one author or one group of authors describing
whole rpm but that is not achievable in one or two weeks.
> > Also the wiki format... For me, if a project uses a wiki as the content
> > management system, it means that it's either a draft of the final website
> > or that they have it just to have a website but that they don't want to use
> > it to attract/educate users. Or even that users are the ones who
> > does/should write the content. I mean, a wiki website does not look like a
> > presentation of a modern project. But you know, DNF's "website" is maybe
> > even worse...
I used procedure suggested by Pavel (use markdown files from wiki to generate
web pages) and here is result . Advantage of having own web pages is also
that we can put there also PDFs, binaries, books about rpm, generated rpm api
and not only pages in wiki format.
> > But definitely I think it's a good start and I like it more than the
> > current
> > site. AFAIK, the goal was mainly to make the website more usable and I
> > think that this was achieved. The critique above is more a suggestion where
> > to focus in the future if there is a will.
> I agree that we need to work on the presentation but as you have already
> figured out, the goal of the first phase to make the information better
> structured to give us some idea what kind of information do we want to have
> there and how to structure it ...
> A few suggestions:
> First of all, I'd move the text about books to the bottom. People looking for
> online information will not be primarily interested in books, no matter if
> they are online or not. To be perfectly honest, I'm not sure about the
> at all, it's informational value is not that high, maybe just making the text
> significantly shorter and leaving just the really important stuff might help
> improving this?
> Second thing that hit me on this page is that some of the items in the
> Packages Documentation are not clickable. Not sure what to think of them, but
> I'd either delete them or link them some other documents. The same applies
> Developer Documentation.
Yes, I know about that, it's just not finished yet.
> Download source:
> First I'd consider renaming this to just Downloads. Other than that I like
> this section, it is quite straightforward and completely fulfills its
> Just one thought: would it make sense to include something like this:
> http://www.gimp.org/downloads/? You know, something like "this is how you
> install rpm on your distro, that might not be rpm-centric".
I am ok with naming this section just "Download".
I am not sure how easy is to install and use rpm in distributions that are
not based on rpm. And for that based on rpm makes such information no sense
because rpm is already installed.
> Getting help:
> You are missing this mailing list in "Getting Help" :-) Other than that it is
> quite ok, even though I'm not completely sure about Reporting Bugs but I
> we need to make that one clear ourselves first ...
> Add the git repo url to the "Contributing Source Code" section and link the
> items in the list of known limitations to relevant documents. Contributing
> Ideas and Contributing Help don't sound like an important sections, I'd
> probably delete them or merge them into one that says "Contribute any other
> way that you think can help us". Last but not least, I wonder if the
> information in "Contributing Documentation" is accurate (requesting access to
> wiki and stuff).
I agree we can delete them completely. People have ideas and RFEs no matter
if we ask for them or not.
> Other than that I think this is a great start, thanks Lubos!
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
More information about the Rpm-ecosystem