Re: Microformats and logical URLs -- mod_rewrite

[Davi Leal]

Victor Engmark wrote:
> Davi Leal wrote:
> > Victor Engmark wrote:
> > > >   https://gnuherds.org/Timeline.php
> > > >                       /news or /timeline ???
> > >
> > > Depends on whether the suggestion to move the data into a sepakrate
> > > news page is followed through.
> >
> > The current Timeline page is separated.  Move what data?
>
> Most of the data on the Timeline page is news. The work items which are not
> done should probably be Savannah tasks (are they already?). How about
> linking the Timeline page only from the "Status: Beta" text? I think that's
> a better targeting of the audience interested in this kind of thing. Casual
> users won't be looking for this information in the main menu - It's for
> people interested in the project, not the functionality.

The Timeline is a general view of the project *roadmap*, not a detailed
task list. For example, it just says "Translate to other languages..." but
the list of languages which the project is being translated is detailed at
the Savannah task manager.

At the webapp apache log, I have seen that people who click several
pages, click too the Timeline. Maybe to know how the project is going,
and to know why there is not job offers, etc.

I think that even when we finish the beta phase, there will be always a
roadmap, a timeline, at least to show an abstract of what we have done,
and to ask, "And now what?" to get ideas.

The task "Move to offices managed by FSF staff" was already registered at
savannah as "Move to another hosting".

There is not specific tasks about the announcement at the Savannah Task
manager. I will create one, and I will link to the last emails which talk
about it.

About the e-vote subject, I think there is not need to create a task at
savannah, due to, as exposed at the e-vote section, if there is some
subject which need voting, initially we can just count emails.


> > > >   https://gnuherds.org/FS_Business_Networks.php

> > something as     /business_network_models  ?
>
> That's long, but maybe it'll do. I believe this is another example of
> information the casual users won't be interested in, and as such, it should
> be moved off of the main menu.

I think the menu must list always all the information which is at the
website. That is accessibility too.

Maybe you mean that this information must be only shown to the logged
users?.


> > > >   https://gnuherds.org/e-Voting_SIG.php
> > > >                       /evote ???
> > >
> > > This could be part of a general FAQ.
> >
> > Yes, but moving it, we will get an empty o removed "Special Interest
> > Groups" section. Maybe it is convenient. I am not sure.
>
> Do we want the "Special Interest Groups" section?

I think it should not be needed. I think even that it is a pain in the
neck.

> Do we need it?

It is good to show, without any doubt, that we are a true-democratic
association.

> Are users gonna go there?

Only users interested specifically on e-voting.


My conclusion is that we must keep it as it is now, and add a savannah
task to note that maybe we should move it at the FAQ section.



> > > It looks as though a lot of the content could be removed:
> > >
> > >    - The links from the "Bringing free software to voting booths"
> > >      article; just link to the article itself, if necessary.
> >
> > It is good we link to the reference from where we have taken the
> > information. Isn't?
>
> Sure, but that's enough information. The current page also contains copies
> of links within that document, which is unnecessary.

Our intention was to list all the possible e-voting options at our page.
So listing the options was the main goal. We just added the reference to
the article from we got those e-vote options.  Do you think yet it is not
right?


> > > >   https://gnuherds.org/Person.php
> > > >                       /person
> > > >
> > > >   https://gnuherds.org/Company.php
> > > >                       /company
> > > >
> > > >   https://gnuherds.org/non-profit_Organization.php
> > > >                       /nonprofit
> > >
> > > All these should IMO be at "/register", with a single link from the
> > > front page, as discussed .
> >
> > This will take some work. Therefore it will not be so easy add this to
> > production. First we will have to fix this kind of thing.  Anyway, I like
> > how directly you get an specific form for fill all the Person, Company or
> > non-profit data.
>
> Yep, but our front page should be as lean as possible, to make sure
> prospective users are immediately aware of where to go to register. It's two
> fewer links on the front page, at the cost of one extra click for those
> users who are trying to register.
>
> As a mitigating measure, I propose we change the registration links from
> "New X?" to "Register X." That way it's clearer what we mean.

OK. So we can the below one as their logical URLs, or something similar:
        /register?e=person
        /register?e=company
        /register?e=nonprofit

However, when the person is already registered and logged, we could use
the below logical URLs, which will point to the same physical Person.php,
etc. URLs:
        /person
        /company
        /nonprofit

or maybe better just:
        /identity   or somethink similar

What do you think?


> > >> https://gnuherds.org/Manage_Job_Offer_Applications.php?JobOfferId=XXX
> >

> > state to: "Received", "In Process", "Ruled out", "Finalist" or "Selected".
> >
> > Maybe this?  "/jobs?action=manage&id=XXX"
>
> That's good, but it's really candidates which are being managed. How about
> "/candidates?action=edit&job_id=XXX"? It's longer, but IMO more clear.

The action is realized over the job or over the candidates?.  The action
is carried out over the candidates of a job offer.

I thought is was better having all action related to jobs as /jobs.

Maybe your option is better, but I am not sure. We can take into account
both options, and decide later.

Davi