Revisiting our project workflow

classic Classic list List threaded Threaded
13 messages Options
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Revisiting our project workflow

Another topic we've touched on at the last IRC chat [1] is our project
workflow. We've decided that it'd be better if each project had a lead
designer, who would take it up to the tentative design phase in cooperation
with the dev who would later work on the project's implementation. The
process would go as follows:
1) A designer and a dev agree to work on a project and make a whiteboard
[2] for it, where everything relevant to the project is published or linked
to. (If a dev wants to work on a project, he contacts the design ML and
hopefully an interested designer shows up. I'm not sure what the best place
for designers to find devs is -- we can discuss that here.)
2) The designer and the dev research what they'll be working on, adding all
useful resources to a "Resources" section on the whiteboard.
3) The designer and the dev formulate a goal and specify the scope of the
project with the help of the design team experts [3]. They also create a
tentative schedule and/or roadmap if possible.
4) The designer writes about the project on the design mailing list,
opening it up to feedback and optionally asking for help.
5) The designer takes the project up to tentative design level, making
sketches, documenting his reasoning, tweaking details and whatever else is
needed along the way. The designer communicates with the dev behind the
project and the design team experts while working on the project.
6) Once the tentative design is done, the designer should again send a
message to the design mailing list and ask for feedback.

Then comes the more broadly applicable decision-making workflow, which I
wrote about in the thread "Our decision-making workflow" [4].

[1] https://wiki.documentfoundation.org/Design/Meetings/2014-06-29
[2] https://wiki.documentfoundation.org/Design/Whiteboards
[3] https://wiki.documentfoundation.org/Design/Team
[4]
http://nabble.documentfoundation.org/Our-decision-making-workflow-td4114935.html

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
V Stuart Foote V Stuart Foote
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

Mirek, *,

Regards para 1): why would there need to be a developer already in agreement to start the process?  It would be nice if one, or more, were already on board, but much of the argument for implementation actually comes from fleshing out the details of what the enhancement should be.

Admittedly  a developer's understanding of the structure of the program and cross platform implementation early in the process improves feasibility of implementation and can provide reasonable  bounds to the design. But, waiting for developers to appear and take an interest otherwise stifles design.

On the other hand, if there is a reasonable flow of good designs from the Design process that result in implementation then that flow becomes the norm.  More developers will "check-in" to see what needs to be worked on, and I'd expect that a fair number would actually make design contributions.   As is now many do their own design work while implementing their code.

Stuart
Rosmaninho Rosmaninho
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

Agree with Stuart, waiting for devs to start the process would severely
limit the work. Why not have the designers brainstorm and come up with
creative solutions even if no dev is present at the beginning.
It would allow for more creativity and cooperation between designers and
even if something fails to atract dev interest it will still result in the
designers better knowing each other, cooperating and in the fostering of a
creative atmosphere.


On Tue, Jul 8, 2014 at 1:18 PM, V Stuart Foote <[hidden email]>
wrote:

> Mirek, *,
>
> Regards para 1): why would there need to be a developer already in
> agreement
> to start the process?  It would be nice if one, or more, were already on
> board, but much of the argument for implementation actually comes from
> fleshing out the details of what the enhancement should be.
>
> Admittedly  a developer's understanding of the structure of the program and
> cross platform implementation early in the process improves feasibility of
> implementation and can provide reasonable  bounds to the design. But,
> waiting for developers to appear and take an interest otherwise stifles
> design.
>
> On the other hand, if there is a reasonable flow of good designs from the
> Design process that result in implementation then that flow becomes the
> norm.  More developers will "check-in" to see what needs to be worked on,
> and I'd expect that a fair number would actually make design contributions.
> As is now many do their own design work while implementing their code.
>
> Stuart
>
>
>
> --
> View this message in context:
> http://nabble.documentfoundation.org/Revisiting-our-project-workflow-tp4114936p4114974.html
> Sent from the Design mailing list archive at Nabble.com.
>
> --
> To unsubscribe e-mail to: [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

Hi Stuart, Pedro,

2014-07-08 14:18 GMT+02:00 V Stuart Foote <[hidden email]>:

> Mirek, *,
>
> Regards para 1): why would there need to be a developer already in
> agreement
> to start the process?  It would be nice if one, or more, were already on
> board, but much of the argument for implementation actually comes from
> fleshing out the details of what the enhancement should be.
>
> Admittedly  a developer's understanding of the structure of the program and
> cross platform implementation early in the process improves feasibility of
> implementation and can provide reasonable  bounds to the design. But,
> waiting for developers to appear and take an interest otherwise stifles
> design.
>
> On the other hand, if there is a reasonable flow of good designs from the
> Design process that result in implementation then that flow becomes the
> norm.  More developers will "check-in" to see what needs to be worked on,
> and I'd expect that a fair number would actually make design contributions.
> As is now many do their own design work while implementing their code.
>

That was my original thought too.
However, working without a dev hasn't worked out for us at all.
Let me give some examples:
* The design of the template dialog was dramatically different from the
proposed design because of a lack of designer/developer communication (and
I'm mostly to fault there). Things like drag-and-drop to create a folder,
design for a single-level hierarchy, a stack switcher-like widget,
single-click-based design, etc. were scrapped mostly because of technical
reasons and that resulted in design problems and a sub-par experience.
* There have been several attempts to design the color picker, but they
haven't been brought to a conclusion. The struggle there was that there was
no way of telling how it would be implemented -- would the current picker
evolve through a series of easy hacks? would it be written from scratch?
would LibreOffice support themes by the time it was worked on?
* The original Android Remote's coverflow-like slide view moved too
quickly. If the dev and the designer worked hand-in-hand, the physics of
the switching slides would be adjusted to a more comfortable speed.

2014-07-08 15:45 GMT+02:00 Pedro Rosmaninho <[hidden email]>:
>
> Agree with Stuart, waiting for devs to start the process would severely
> limit the work. Why not have the designers brainstorm and come up with
> creative solutions even if no dev is present at the beginning.
>

There's no restriction on brainstorming for designers, but whiteboards
aren't a place for those. Designers can post their ideas on their user
pages or on networks like DeviantArt.

Whiteboards should be designed with implementation in mind, and that
requires dev cooperation.

It would allow for more creativity and cooperation between designers and
> even if something fails to atract dev interest it will still result in the
> designers better knowing each other, cooperating and in the fostering of a
> creative atmosphere.
>

There are a number of things that designers can work on that would have dev
support or that don't require dev support (e.g. working on icon sets,
reporting and bringing attention to design bugs, ...).

There's still room for mockups and prototypes without dev backing, but that
should be left to user pages and DeviantArt.

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Rosmaninho Rosmaninho
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

That makes sense Mirek. Thanks for clearing the reasoning behind the need
for devs!

However, I would suggest creating an area where designers could share
designs and discussions between themselves under the LO umbrella and not
spread around Deviantart or their user pages.
Maybe a LO design forum where designers could discuss with each others and
maybe even get some devs to take a peek at it?


On Tue, Jul 8, 2014 at 11:32 PM, Mirek M. <[hidden email]> wrote:

> Hi Stuart, Pedro,
>
> 2014-07-08 14:18 GMT+02:00 V Stuart Foote <[hidden email]>:
>
> Mirek, *,
>>
>> Regards para 1): why would there need to be a developer already in
>> agreement
>> to start the process?  It would be nice if one, or more, were already on
>> board, but much of the argument for implementation actually comes from
>> fleshing out the details of what the enhancement should be.
>>
>> Admittedly  a developer's understanding of the structure of the program
>> and
>> cross platform implementation early in the process improves feasibility of
>> implementation and can provide reasonable  bounds to the design. But,
>> waiting for developers to appear and take an interest otherwise stifles
>> design.
>>
>> On the other hand, if there is a reasonable flow of good designs from the
>> Design process that result in implementation then that flow becomes the
>> norm.  More developers will "check-in" to see what needs to be worked on,
>> and I'd expect that a fair number would actually make design
>> contributions.
>> As is now many do their own design work while implementing their code.
>>
>
> That was my original thought too.
> However, working without a dev hasn't worked out for us at all.
> Let me give some examples:
> * The design of the template dialog was dramatically different from the
> proposed design because of a lack of designer/developer communication (and
> I'm mostly to fault there). Things like drag-and-drop to create a folder,
> design for a single-level hierarchy, a stack switcher-like widget,
> single-click-based design, etc. were scrapped mostly because of technical
> reasons and that resulted in design problems and a sub-par experience.
> * There have been several attempts to design the color picker, but they
> haven't been brought to a conclusion. The struggle there was that there was
> no way of telling how it would be implemented -- would the current picker
> evolve through a series of easy hacks? would it be written from scratch?
> would LibreOffice support themes by the time it was worked on?
> * The original Android Remote's coverflow-like slide view moved too
> quickly. If the dev and the designer worked hand-in-hand, the physics of
> the switching slides would be adjusted to a more comfortable speed.
>
> 2014-07-08 15:45 GMT+02:00 Pedro Rosmaninho <[hidden email]>:
>
>> Agree with Stuart, waiting for devs to start the process would severely
>> limit the work. Why not have the designers brainstorm and come up with
>> creative solutions even if no dev is present at the beginning.
>>
>
> There's no restriction on brainstorming for designers, but whiteboards
> aren't a place for those. Designers can post their ideas on their user
> pages or on networks like DeviantArt.
>
> Whiteboards should be designed with implementation in mind, and that
> requires dev cooperation.
>
> It would allow for more creativity and cooperation between designers and
>> even if something fails to atract dev interest it will still result in the
>> designers better knowing each other, cooperating and in the fostering of a
>> creative atmosphere.
>>
>
> There are a number of things that designers can work on that would have
> dev support or that don't require dev support (e.g. working on icon sets,
> reporting and bringing attention to design bugs, ...).
>
> There's still room for mockups and prototypes without dev backing, but
> that should be left to user pages and DeviantArt.
>

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

2014-07-09 0:45 GMT+02:00 Pedro Rosmaninho <[hidden email]>:

> That makes sense Mirek. Thanks for clearing the reasoning behind the need
> for devs!
>
> However, I would suggest creating an area where designers could share
> designs and discussions between themselves under the LO umbrella and not
> spread around Deviantart or their user pages.
> Maybe a LO design forum where designers could discuss with each others and
> maybe even get some devs to take a peek at it?
>
>
Reda suggested to use GitHub, like Gnome does [1].
There was also an effort underway to create a web application exactly for
this purpose -- Glitter Gallery [2]. I'm not sure if it's in a usable
state, though.

So... GitHub for now?

[1] https://github.com/gnome-design-team/
[2] https://github.com/glittergallery/GlitterGallery


>
> On Tue, Jul 8, 2014 at 11:32 PM, Mirek M. <[hidden email]> wrote:
>
>> Hi Stuart, Pedro,
>>
>> 2014-07-08 14:18 GMT+02:00 V Stuart Foote <[hidden email]>:
>>
>> Mirek, *,
>>>
>>> Regards para 1): why would there need to be a developer already in
>>> agreement
>>> to start the process?  It would be nice if one, or more, were already on
>>> board, but much of the argument for implementation actually comes from
>>> fleshing out the details of what the enhancement should be.
>>>
>>> Admittedly  a developer's understanding of the structure of the program
>>> and
>>> cross platform implementation early in the process improves feasibility
>>> of
>>> implementation and can provide reasonable  bounds to the design. But,
>>> waiting for developers to appear and take an interest otherwise stifles
>>> design.
>>>
>>> On the other hand, if there is a reasonable flow of good designs from the
>>> Design process that result in implementation then that flow becomes the
>>> norm.  More developers will "check-in" to see what needs to be worked on,
>>> and I'd expect that a fair number would actually make design
>>> contributions.
>>> As is now many do their own design work while implementing their code.
>>>
>>
>> That was my original thought too.
>> However, working without a dev hasn't worked out for us at all.
>> Let me give some examples:
>> * The design of the template dialog was dramatically different from the
>> proposed design because of a lack of designer/developer communication (and
>> I'm mostly to fault there). Things like drag-and-drop to create a folder,
>> design for a single-level hierarchy, a stack switcher-like widget,
>> single-click-based design, etc. were scrapped mostly because of technical
>> reasons and that resulted in design problems and a sub-par experience.
>> * There have been several attempts to design the color picker, but they
>> haven't been brought to a conclusion. The struggle there was that there was
>> no way of telling how it would be implemented -- would the current picker
>> evolve through a series of easy hacks? would it be written from scratch?
>> would LibreOffice support themes by the time it was worked on?
>> * The original Android Remote's coverflow-like slide view moved too
>> quickly. If the dev and the designer worked hand-in-hand, the physics of
>> the switching slides would be adjusted to a more comfortable speed.
>>
>> 2014-07-08 15:45 GMT+02:00 Pedro Rosmaninho <[hidden email]>:
>>
>>> Agree with Stuart, waiting for devs to start the process would severely
>>> limit the work. Why not have the designers brainstorm and come up with
>>> creative solutions even if no dev is present at the beginning.
>>>
>>
>> There's no restriction on brainstorming for designers, but whiteboards
>> aren't a place for those. Designers can post their ideas on their user
>> pages or on networks like DeviantArt.
>>
>> Whiteboards should be designed with implementation in mind, and that
>> requires dev cooperation.
>>
>> It would allow for more creativity and cooperation between designers and
>>> even if something fails to atract dev interest it will still result in
>>> the
>>> designers better knowing each other, cooperating and in the fostering of
>>> a
>>> creative atmosphere.
>>>
>>
>> There are a number of things that designers can work on that would have
>> dev support or that don't require dev support (e.g. working on icon sets,
>> reporting and bringing attention to design bugs, ...).
>>
>> There's still room for mockups and prototypes without dev backing, but
>> that should be left to user pages and DeviantArt.
>>
>
>

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Daniel Hulse Daniel Hulse
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

A forum might be a good idea, as it would reduce the number of barriers that keep people interested in designing for Libreoffice. KDE seems to be having a good deal of progress with their visual design group, and they use a forum ( https://forum.kde.org/viewforum.php?f=285 ). Under this model, however, it might be necessary to have a community manager and moderators guide work and maintain the forum.
mirek2 mirek2
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

I agree that a forum is probably more fitting for design discussions
(especially if it allows attachments), provides more privacy (your e-mail
address isn't pubilc), and I have to admit I would've been more comfortable
with a forum when I first joined the mailing list.

That said, we shouldn't spread out our internal conversations over too many
channels, so if we agree to go with a forum, we'd need to let go of our
mailing list. We'd also need the Document Foundation to host our forum.

Would everybody here agree to move to a forum if TDF agreed to host it? We
should discuss this on our IRC chat this week.


2014-07-20 10:04 GMT+02:00 Daniel Hulse <[hidden email]>:

> A forum might be a good idea, as it would reduce the number of barriers
> that
> keep people interested in designing for Libreoffice. KDE seems to be having
> a good deal of progress with their visual design group, and they use a
> forum
> ( https://forum.kde.org/viewforum.php?f=285 ). Under this model, however,
> it
> might be necessary to have a community manager and moderators guide work
> and
> maintain the forum.
>
>
>
> --
> View this message in context:
> http://nabble.documentfoundation.org/Revisiting-our-project-workflow-tp4114936p4116123.html
> Sent from the Design mailing list archive at Nabble.com.
>
> --
> To unsubscribe e-mail to: [hidden email]
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>
>

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
K-J LibreOffice K-J LibreOffice
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

Am 23.07.2014 um 16:58 schrieb Mirek M.:

> I agree that a forum is probably more fitting for design discussions
> (especially if it allows attachments), provides more privacy (your e-mail
> address isn't pubilc), and I have to admit I would've been more comfortable
> with a forum when I first joined the mailing list.
>
> That said, we shouldn't spread out our internal conversations over too many
> channels, so if we agree to go with a forum, we'd need to let go of our
> mailing list. We'd also need the Document Foundation to host our forum.
>
> Would everybody here agree to move to a forum if TDF agreed to host it?

I don't think that we can easily change our workflow to a forum and
leave the ml for the design project. It should be a general decision by
the BoD because all projects should work in one way.
And I personally won't work in a forum because there is no profit for me
against now. But many disadvantages:
- no sheduling AFAIK
- up to now you need an external Open ID which I don't want to use
- what about archiving and finding?
- How to get a message that something new is in there as long as I'm not
directly involved?

IMHO we will get the biggiest advance by a redmine project. There we can
ticketing, sheduling, archiving, linking, assigning, observing, etc.
I requested a design project in redmine as supposed [1] [2].

[1] https://redmine.documentfoundation.org/issues/571
[2] http://listarchives.libreoffice.org/global/design/msg06696.html

Give Redmine a try.

> We
> should discuss this on our IRC chat this week.

I'm not able to be within the IRC on sunday.

--
Grüße
k-j

Member of TheDocumentFoundation
http://www.documentfoundation.org/foundation/members/
http://de.libreoffice.org
http://wiki.documentfoundation.org/

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Rosmaninho Rosmaninho
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

And why not both?

Get a forum for constant idea discussion, and for outside people to chip
in, give their opinion and even atract new blood and use redmine to
structure projects when these are decided to move forward.

And not wanting to use an external ID as a reason is a really poor one.
Don't you have accounts in any forum or message board besides this one?


On Thu, Jul 24, 2014 at 12:22 PM, K-J LibreOffice <[hidden email]>
wrote:

> Am 23.07.2014 um 16:58 schrieb Mirek M.:
>
>  I agree that a forum is probably more fitting for design discussions
>> (especially if it allows attachments), provides more privacy (your e-mail
>> address isn't pubilc), and I have to admit I would've been more
>> comfortable
>> with a forum when I first joined the mailing list.
>>
>> That said, we shouldn't spread out our internal conversations over too
>> many
>> channels, so if we agree to go with a forum, we'd need to let go of our
>> mailing list. We'd also need the Document Foundation to host our forum.
>>
>> Would everybody here agree to move to a forum if TDF agreed to host it?
>>
>
> I don't think that we can easily change our workflow to a forum and leave
> the ml for the design project. It should be a general decision by the BoD
> because all projects should work in one way.
> And I personally won't work in a forum because there is no profit for me
> against now. But many disadvantages:
> - no sheduling AFAIK
> - up to now you need an external Open ID which I don't want to use
> - what about archiving and finding?
> - How to get a message that something new is in there as long as I'm not
> directly involved?
>
> IMHO we will get the biggiest advance by a redmine project. There we can
> ticketing, sheduling, archiving, linking, assigning, observing, etc.
> I requested a design project in redmine as supposed [1] [2].
>
> [1] https://redmine.documentfoundation.org/issues/571
> [2] http://listarchives.libreoffice.org/global/design/msg06696.html
>
> Give Redmine a try.
>
>
>  We
>> should discuss this on our IRC chat this week.
>>
>
> I'm not able to be within the IRC on sunday.
>
> --
> Grüße
> k-j
>
> Member of TheDocumentFoundation
> http://www.documentfoundation.org/foundation/members/
> http://de.libreoffice.org
> http://wiki.documentfoundation.org/
>
>
> --
> To unsubscribe e-mail to: [hidden email]
> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
> unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
dennisroczek dennisroczek
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

/me just followed the discussion by accident.
I know that redmine has also the possibility to activate in the config
per project a forum. I have no experience, but that would solve many
"cons and problems" of k-j and many others to. There is also work
ongoing to provide an Open-ID server by the TDF to get a single-sign-on
on all services by the TDF :-)

So request a design project in redmine and request that the forum (at
least fora test) gets activated. (just a technical note, I cannot
provide any content regarding design!)

<quote removed />


--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
K-J LibreOffice K-J LibreOffice
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

Am 25.07.2014 um 03:04 schrieb Dennis Roczek:
> /me just followed the discussion by accident.
> I know that redmine has also the possibility to activate in the config
> per project a forum. I have no experience, but that would solve many
> "cons and problems" of k-j and many others to. There is also work
> ongoing to provide an Open-ID server by the TDF to get a single-sign-on
> on all services by the TDF :-)
>
> So request a design project in redmine

It is online:
https://redmine.documentfoundation.org/projects/design

I'm for now the only manager for this.
Tell me who will get a manager role.
Of course: Mirek and Astron (if they want)

> and request that the forum (at
> least fora test) gets activated. (just a technical note, I cannot
> provide any content regarding design!)

The forum is activated now (but not online). I think it is a question of
time.

--
Grüße
k-j

Member of TheDocumentFoundation
http://www.documentfoundation.org/foundation/members/
http://de.libreoffice.org
http://wiki.documentfoundation.org/

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
K-J LibreOffice K-J LibreOffice
Reply | Threaded
Open this post in threaded view
|

Re: Revisiting our project workflow

Hi all,
Am 25.07.2014 um 09:29 schrieb K-J LibreOffice:

> The forum is activated now (but not online). I think it is a question of
> time.

A forum is online [1]. I have to not only activate one but have to
create one  ;-).

[1] https://redmine.documentfoundation.org/projects/design/boards

--
Grüße
k-j

Member of TheDocumentFoundation
http://www.documentfoundation.org/foundation/members/
http://de.libreoffice.org
http://wiki.documentfoundation.org/

--
To unsubscribe e-mail to: [hidden email]
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted