spreadubuntu team mailing list archive

["Rubén Hubuntu" <hubuntu@xxxxxxxxx>]

between the lines...

On Thu, Jul 17, 2008 at 2:17 PM, Pierre Vorhagen <pvorhagen@xxxxxxxxx>
wrote:

> > * What kind of services will the diy site offer, that is for
> > example, upload, download, search, version control, etc.
>
> - Imo, diy.su.com offers mainly a download and an upload section.
> - Upload is a simple section, you get straight on an Upload page, where you
> enter all information we need and click "Submit", that's it.
> - Download gives us a great list of documents, one per row, with several
> columns to sort by. When you click on a document, you come to a gnome-look
> type "profile-page" relevant to the document, with a short presentation,
> version, available languages, maybe a 200*200 screenshot, the ability to
> read and post comments, and a big "Translate" button. (This button would
> re-direct to launchpad I suppose) Also, you can give a rating to a document.
> - As you can see on my mock-up, there is a quick filter, enabling to
> immediately filter the list of documents below (in the Download section ofc)
> but as this is relatively limited, you can access an "Advanced Search" page,
> by clicking on the link. On that advanced search page, you can search per
> multiple criteria, using OR/AND/XOR/NOT between keywords... well, an
> advanced search.
> - There is openID registration/login.
> - Also the diy site links back to a couple of sites of our choice. (
> ubuntuvideo.com for one, they are the video repository)
> - And that's it! Imho, and mpt from Launchpad was of the same opinion, more
> functionality just makes the site less usable and efficient. We have to go
> straight to the essence of our service to be competent.
>

We should start with a simple approach (I like the Upload/Download idea)
which should be understandable for our users (Upload = Share and Spread,
Download = Get)


>
> > * What information is required for the static site?
>
> - You're talking about the Site part, not the diy part. To be honest, I
> don't care for the moment, we fixed our focus on diy for now.
>

As I've said before this part is more important than I thought initially,
but we need the DIY part of the SU up first. A parallel work could be
started by those interested but our main efforts should be in the DIY site.


>
> > * How big will the documents be that we're going to offer?
>
> - This leads us to another point I thought about:
>

Big enough to be usable in the web and for other uses a SVG o EPS should do
(preferably, of course, a SVG)..


>
> * Which *type* of documents do we support?
>
> - Imo, we have to set someone on analysing the common document-types. I
> suppose all image files, all OOo files, vector graphics of course, anything
> else? Sound files? (podcasts, speeches...)
>

Marketing material and Artwork. This should include every single imaginable
type of content that can be shared according to our Licensing policy (which
of course we have to create).


> > * What kind of load are we expecting?
>
> - I am over-questioned there as I have no idea of how many people will be
> interested in our content. But if we pull this through properly, I think we
> can count with a relatively big load, if we really are the central resource.
>

If our campaigns are succesful and the material gets linked directly from
our site it is likely that we will have a high load and bandwidht usage. But
since Canonical will most likely host us if we succeed that should not be a
problem.


>
> > * How much disk-space are we going to need?
>
> - That will depend on the type of files we accept, and the size limits we
> define for each type of document.
>

Not an issue. See above.


>
> > * How much band-width?
>
> - This question bothered me too some time ago. Someone suggested to pull
> everything over from launchpad once a day. Imo, that is useless
> transferring. It would be more effective and bandwidth saving to do a simple
> synchronisation, pulling over to diy only modified documents. For the actual
> calculation, we need to know how many documents and of which size we're
> awaiting.
>

Not an issue either. See above.


>
> > * Who will be able to do what to the site?
>
> - Good point. As I see things, there will be 4 different status'.
> - First: the user without log-in: he can simply download documents. If he
> wants to translate he'll need a log-in anyway to work in launchpad, and if
> he's uploading it means that he's probably an active Ubuntero or somehow
> interested in making Ubuntu progress, so he'll probably already have a LP
> log-in or be pleased to get one. He also can't comment on documents. This
> gives us a good control on origin of incoming documents, and reduces spam.
> - Second: the logged user: he is the real user of the site, he can
> download, upload, translate and comment.
> - Third: SU moderators: they are responsible for making sure there is no
> spam in the comments, for checking all incoming documents before
> synchronisation, making sure the tags are correctly applied (not tag a
> presentation as "flyer" for instance), supervising translations...
>    If this turns out to be too much work, we can always divide this group
> into one moderation group responsible for comments and tags, and one
> responsible for translation for example...
> - Fourth: this is a background role, admins: This will be us I suppose, or
> at least the people behind the actual site and infrastructure, although they
> can also be part of the moderators, they make sure there are no technical
> problems concerning diy, synchronisations, etc...
>

Totally agree with Pierre.


>
> > * What kind of access controls will there be?
>
> - Access controls? Well there is openID... I'm not sure what you mean, I
> hope I answered this question above.
>

See Pierres answer above :)


>
> > * Which languages will we support?
>
> - Very good point too, I already thought about this too. We have to respect
> that numerous people don't speak English.
> - The un-logged user, sees the site in his main browser language or in
> English (still to be discussed).
> - The logged user sees the language in his primary preferred language in
> launchpad. (huh? I know, there is no primary preferred language in
> launchpad, you can only select a list of languages in no order, I filed a
> bug about this here just yesterday, take a look: <
> https://bugs.edge.launchpad.net/launchpad/+bug/249111>)
>   If this primary preferred language business turns out not to be possible,
> I suggest we use English, if it is in the users preferred language list, and
> his browser language if English is not in the list. (We have no way of
> seeing which language he prefers if he's got Portuguese and Spanish for
> example.)
>

I assume that having a flag for the supported languages in the upper right
corner will do. By the time we have a usable demo (mid-august) the site will
be up in Spanish and English.


>
> > * What interface elements will need to be translated?
>
> - Everything. The elements describing a document and so on are translated
> with the document itself, diy will be completely translated. At least I'd
> like it to be.
>

Yes, everything that the translators are finished with. We will solve this
issue easily by using language tags on our material.


>
> > * Who will be the audience for this site and what requirements do
> > they have?
>
> - Audience is for one part the active Ubuntero or marketeer, this is our
> primary target, and for two it is the normal user, that came onto diy
> through the Site part, willing to spread his new OS around him.
> - For the first type, they need a straight-forward infrastructure, that is
> mostly effective, and well integrated with launchpad. They are probably used
> to contributing and don't want useless clicking. It is mainly in that optic
> I designed the mock-ups and I think it's the most important one.
> - For the second type of user, the documents need to be intuitively found,
> that is, if he's got no idea what exists, he can easily come across
> something of great quality and use... maybe think about optimizing the
> automatic search filter to sort first by the highest rated or something...
>

Campaign entusiast and users alike. Maybe people looking for Ubuntu material
for the press or the blogosphere. Every uploader MUST have a LaunchPad
account since we are using OpenID with LP as the ONLY provider. No local
users, just a local copy of the UserNames form LaunchPad.


>
> > * Where will we source our initial material?
>
> - A team will have to be set-up to go out and seek for it, we already have
> a nice collection on the Marketing team and on the SU wiki. Also, will we
> call the LoCo teams to submit all their material.
>

The compilation has alerady started:

https://wiki.ubuntu.com/MarketingTeam/SpreadUbuntu/diy/Materials

All LoCo teams will be asked to help with this and I believe that asking
them to include this activity in their monthly report could be a good idea
to spread and let people know about the existence of the SU project. This
cannot be done before we have our structure demo up and running, so the
material we will use till the mid-august demo will be the material compiled
by ourselves.

I believe dividing the material in countries or/and languages and then
implementing (and agreeing upon) the Classification system proppossed by
Pierre should help us:

https://wiki.ubuntu.com/MarketingTeam/SpreadUbuntu/diy#head-7b73d553a3987aaab369cd5c7eeb0d35e071e71e



>
> > * What kind of version control will we use for the site itself?
>
> - I suggest keeping the site code in launchpad and using bazaar. I'm not
> yet completely familiar with this but I'm trying to get the grips with its
> functioning...
>

We go bazaar just because we can ;)


>
>
> I described how I saw the classification system and how I would treat
> documents in different languages in the wiki, I will put it in here for
> additional information:
>
> Imagine the same document exists in 6 languages. A person filtering by the
> document type and purpose would see 6 entries for the same document. Rather
> pointless. So first I thought of having one entry per document, and not per
> document per language, but that disables the filtering by language in the
> list... still following me? So in my opinion, the best solution is to use
> the 'preferred languages' associated with ones launchpad profile, as we use
> openID, which will considerably reduce the number of redundant documents.
> Only appear the documents in english + the languages specified in LP. As a
> potential translator will have his preferred languages set in LP, he won't
> miss a document he's susceptible to translate.
>
> What's the deal with the numbers? (see first mock-up I made) As you see, I
> put a serial number. There will be **one per document**, however many
> languages are associated with it. (So for example, if there are 3 versions
> of a document, the references will be: 4215-fr, 4215-ru and 4215-it.) The
> number is not random of course, we will have to analyse this in depth if we
> need any information in it, but at first sight, first number can be the type
> and the ones following serve only identification purposes. It allows quick
> designation of one specific document. If you look at the mockup you'll see
> several other criteria, the title will be different per language, the date
> also (last modified if corrections have been made), and the rating will be
> the same for every language.
>
>
> Now, to a couple of important questions of my own I would like to be
> precised: How exactly will diy and launchpad work together? What will a
> document be in LP? (a project? oO)
>

Bazaar and LaunchPad will be the real repository. Bazaar helps us to commit
material (change, update, add/remove) and keep tracks of the changes and its
translations through branches (branches probably defined by language or
users or both).

Every single thing that we can upload to a server can be a element for
commit in Bazaar and be manageable then through LaunchPad. It will be an
element into the su project in LaunchPad. Instead of code and text files
only, we will have hte site code and hte material uploaded as binaries or
text (depending on what they are).


>
>
> That's about it for now, sorry this got a bit long, but we've got to get
> into the business now. Don't hesitate to discuss and add to what I wrote
> above.
>


It's good to see that we are starting to discuss the *real* issues because
we need to get going. Hopefully the meeting on Saturday will help us clarify
many of the issues.

We may need an agenda for the meeting. I have no time now, but if someone
can step up and give us a hand it would be wonderful.


>
> have a nice day,
> Pierre
>

Best regards,

Rubén.
https://launchpad.net/~huayra