Mailinglist Archive: opensuse-factory (282 mails)

[Andreas Jaeger <aj@xxxxxxxxxx>]

On Thursday 30 September 2010 06:22:30 Rajko M. wrote:
> On Wednesday 29 September 2010 07:01:22 Andreas Jaeger wrote:
> ...
>
> > > Exists as in I can add my self
> >
> > But you cannot add others that you might think are interested.
>
> Is this desirable?
> Some prank can add anyone to any feature.

It is the same with bugzilla at the moment.  Everybody can do everything. 
I'd like to have openFATE as open as possible - but if this does not work, 
we have to change it.

> > > * List of all features in state "Eval by team lead (TL)"
> > > (Marketplace/open for grab) with specific tags
> > > ...
> >
> > Currently we do not have team leads for openSUSE, so I would rename
> > the complete entry from "Evaluation by team lead" to something else.
>
> We will have to create someone that is able and held responsible to make
> decision. I'm really tired to repeat that flat "structure" as it is now
> (we are all members except few that are board) will bring nothing, just
> as it did not bring anything in the past. There must be known member
> that will be called team lead for each and every team.

Exactly: So, the evaluatoin happens with the change from "New" to 
"Marketplace".  My proposal is that for each tag, we have an expert (or 
team lead) that does the evaluation.  So, for the tag "GNOME" it could be 
dimstar, for the tag "KDE" it might be Will etc.

Does this make sense?
 
> > The
> > proposal was "up for grab" or "marketplace" - and it can be taken by
> > anybody not only students ;)
>
> Students need projects to apply their knowledge, teachers need projects
> to give students assignments, the rest of the world can grab open
> features, but even that should be organized. In other words we want to
> know who works on some feature, what he/she/they did, how many bugs
> they have ahead, where they keep files, if there are subprojects their
> relation (dependencies), approximate time to accomplish, and probably
> more that I can't think of. (not a project manager)

How do we want to do this in the best way? I think that's an important 
process beyond the tool...

I've seen in Maemo the rule that somebody can only signup for three tasks 
at a time to not overcommit himself. But what of these rules do we want to 
handle with tool support - and which - and which with written rules?

> > > ** Requirement: at least one tag set
> > > Where the "tag" is?
> >
> > I guess we should define a couple of known tags that then others can
> > search for in the second step.
>
> When you start typing there will be drop down list. Looking at the
> content it appear to me that is not browser attempt to offer words that
> were previously used.

Yes, the browser offers the previously used ones.  Still we might want to 
define a smaller subset for evaluation.

> > > If that is top left keyword, then it needs some work. Now it is
> > > buggy. One has to write "kernel_driver" to get that added as a
> > > single tag, instead of plain language "kernel driver". It is
> > > intuitive to use comma as separator, just as it will appear after
> > > adding few keywords.
> >
> > Yes, the top left keyword and let's write this one up as well.
> > Adding with commas work.
>
> I used this feature to test adding tags:
> https://features.opensuse.org/305080
>
> Using comma in "runlevel, inittab" result in:
> "You entered an malformed url!"
> and only inittab is added.
>
> "run level" results in added tags "run, level".
>
> In other words it accepts space separated single words.

so, let's get this changed ;) 
> ...
>
> > > Where do we put improvements to user interface?
> >
> > See the last part "Additionally the following convenience and
> > usability improvements should be done:" - I split it now on the wiki
> > page.
>
> OK.
>
> > > By now children know what is word "edit", but pencil icon is not so
> > > clear. I haven't seen that kind of edit command often used.
> > >
> > > Editor itself is a bit on user unfriendly side.
> > > You can't see how formatting will look before adding a comment.
> > > Even, 10 years old Wikipedia that is not example of user friendly
> > > editing has Preview button.
> >
> > Added.
> >
> > > Save on top of the screen, that is out of sight even in modestly
> > > commented features, is another "feature" that should be places right
> > > next to the edited part.
> >
> > I'm not sure I understand what you mean, could you rephrase this,
> > please?
>
> It is about save feature after some of entries are changed. I know that
> this is the case for adding the comment. Save feature is on the top of
> the screen. "This feature has unsaved changes! Please save when you are
> done." [Save feature] [Revert changes]

Now I see - could you add this to the wiki, please?

> I just tested on https://features.opensuse.org/305929 that has enough
> comments. Page reloads and user can see warning that feature is not
> saved, but comment is few scrolls away below that.
> Preview, Save, Cancel (or discard changes) should be next to the edit
> window, like in MediaWiki. (added this to the wiki page)
>
> BTW, in this moment I can only "discard changes" loosing all that is
> written, there is no way to go back to edit window. Workflow as it is
> now is really useless.
>
> > > On the other hand anyone can change whole feature description
> > > changing completely what the feature is about. Again, Wikipedia has
> > > that solved with history for a very long time.
> > >
> > > Maybe good old MediaWiki with few extensions should be considered as
> > > feature tracker.
> >
> > An option as well - it just does not integrate with the way Novell
> > works right now but if it benefits us so much then let's use the
> > superior solution, Perhaps we need to step also back and discuss the
> > whole process first more instead of deciding on tools,
>
> I think so.
> Current tool is replica of Bugzilla that has only one advantage comments
> can be threaded, but at the same time more then one missing feature,
> like easy editing of entries, but also one "feature" - easy editing of
> description.

Extra feature is multi-product handling - not really needed for openSUSE as 
well as several evaluation steps and a handling of roles.  
 
> We should rethink how to connect feature request with pages that will
> track progress on feature development. Currently openFATE is isolated
> island used to receive feature request, nothing else that will make
> life of potential contributors easier is there.
>
> One option is to use Sourceforge for project (feature) development, as
> they offer complete set of tools for that. The only missing component
> there is Build Sevice, but that can be linked too.
> In that case we need some frame on each site that will link to other
> relevant sites (pages, articles, rpms).

I prefer to have something more integrated and don't want to rely on 
sourceforge at all.
 
> > Thanks for the feedback, I'm reworking the page now a bit, hope this
> > helps, Andreas
>
> You are welcome and thanks for prompt response.

Sorry, it took me a bit longer this time ;)

Andreas
-- 
 Andreas Jaeger, Program Manager openSUSE,  aj@{novell.com,opensuse.org}
  Twitter: jaegerandi | Identica: jaegerandi
   SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
    Maxfeldstr. 5, 90409 Nürnberg, Germany
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx